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ABSTRACT 


Today, the U.S. military relies upon space-based technology for a myriad of 
functions from precision navigation to satellite communication. Satellites greatly enable 
the modem American military and particularly empower special operations forces across 
the globe, supporting decentralized and geographically disparate operations. However, 
the U.S. is highly reliant upon this technology and thus increasingly vulnerable with 
potential adversaries undoubtedly possessing, or at least cultivating, the ability to attack 
America's space-based infrastructure. As a safeguard against such vulnerabilities, 
nanosatellites, cube satellites (CubeSats), and other small satellites are a low-cost and 
expedient solution to build redundancy and resiliency, offering unique options as an 
alternative to traditional satellite systems. To support this hypothesis, this thesis provides 
such an alternative: A Software Assisted VHP Information Overhead Relay-CubeSat 
(SAVIOR-Cube). SAVIOR-Cube is a software-defined radio (SDR) payload operating as 
a very high frequency (VHP) relay via a nanosatellite in low Earth orbit. This thesis 
demonstrates the depth of the problem a payload such as SAVIOR-Cube could solve, the 
applicability of nanosatellite solutions to U.S. forces today, and the results of extensive 
testing, culminating with a proof of concept high-altitude balloon flight. Nanosatellites 
are a viable alternative to traditional space-based infrastructure—a solution to a critical 
vulnerability. 
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EXECUTIVE SUMMARY 


Today, the U.S. military relies heavily upon space-based technology for a myriad 
of functions from precision navigation to satellite communication and is thus vulnerable to 
potential adversaries cultivating the ability to attack the United States' space-based 
infrastructure. As a safeguard against such vulnerabilities, nanosatellites and cube satellites 
(CubeSats) are a low-cost and expedient method for building redundancy, offering unique 
options as an alternative to traditional satellite systems. This thesis provides such an 
alternative via the Software Assisted VHP Information Overhead Relay-CubeSat 
(SAVIOR-Cube): a software-defined radio (SDR) payload operating as a very high 
frequency (VHP) relay via a nanosatellite in low Earth orbit, as Pigures ES-1 and ES-2 
depict. This thesis demonstrates the depth of the problem a payload such as SAVIOR-Cube 
could solve, the applicability of nanosatellite solutions to U.S. forces today, and the results 
of extensive testing, culminating with a proof of concept high-altitude balloon (HAB) 
flight. 



Eigure ES-1. Concept of Operations 










A. 


METHOD AND APPROACH 


A research-based methodology coupled with in depth experimentation designed to: 

• illuminate the vulnerability a dependence on space-based systems creates 

• research potential nanosatellite solutions and build a model constellation 
and concept of operations for a VHP nanosatellite relay 

• design, build, and iteratively test a prototype SAVIOR-Cube payload 

• launch SAVIOR-Cube via a HAB to test it in a near-space environment 
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Figure ES-2. SAVIOR-Cube 


B. TESTING AND RESULTS 

Extensive research, experimentation, and testing resulted in: 

• communication across a simulated distance of 100 km 

• a maximum altitude of 21 km (70,000 ft) and communication over a 
maximum slant-range of 36 km 

• thirty minutes of operations at altitude, successfully sending and receiving 
fourteen separate transmissions 

• a successful proof of concept test and design for a VHE nanosatellite 
relay—a solution for a critical vulnerability 
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I. INTRODUCTION AND BACKGROUND 


In the 1950s, the dawn of the space era led to scientific breakthroughs and 
technological innovations that forever changed the human way of life and still shape the 
way people connect across the globe. Today, modern governments and mi litaries are highly 
dependent on space technology to function, and the United States relies upon it to wage its 
modem style of war. Space technology enables the United States to conduct quick, decisive 
operations with decentralized units and precision weapons—the modern American way of 
war.l Furthermore, Special Operations Forces (SOF), the force of choice for America’s 
Global War on Terrorism, often operate in remote locations and rely heavily on satellites 
to support a decentralized command structure, coordinating geographically disparate yet 
strategically connected operations. Though space-based technology greatly empowers U.S. 
SOF, the United States is teetering dangerously close to an overreliance on this technology. 
Access to space-based resources is finite, and every unit in the U.S. military, SOF included, 
does not have instantaneous access to this advanced technology for every mission. Beyond 
resource limitations, an adversary capable of jamming satellite signals, disabling U.S. 
ground stations, or attacking U.S. satellites could cause costly failures across the spectmm 
of operations. Moreover, the nature of special operations makes SOF particularly 
vulnerable to such anti-satellite attacks. 

While the United States relies on space-based technology for a multitude of 
functions from positioning, navigation, and timing (PNT) to overhead imagery, nowhere 
is this high reliance more evident than in the use of satellite communication (SATCOM). 
Sophisticated communication systems such as SATCOM, coupled with decentralized 
command structures that inform and empower subordinates, have led to unprecedented 
awareness for commanders on the battlefield that greatly increases combat effectiveness.^ 
Across the globe, U.S. forces use satellites to conduct encrypted video-teleconferences, to 


1 Phillip S. Meilinger, “American Military Culture and Strategy,” Joint Forces Quarterly 46 (October 
2007): 85. 

^ Ryan Grauer, Commanding Military Power: Organizing for Victory and Defeat on the Battlefield 
(Cambridge: Cambridge University Press, 2016), 53. 
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access classified and unclassified networks, and to conduct real-time voice communication. 
U.S. SOF, in particular, utilize this paradigm to operate remote outposts in otherwise poorly 
connected and isolated regions of the globe, relying upon satellites orbiting the Earth to 
provide real-time links to higher headquarters on the other side of the planet. However, 
absent such capabilities, U.S. forces would be severely disadvantaged and U.S. SOF would 
find their current modus operandi—decentralized operations in remote regions— 
increasingly difficult to execute. Making matters worse, while safeguards exist for strategic 
assets like intercontinental ballistic missiles, little exists in the way of protection or 
contingency plans in the event of an attack on U.S. satellite infrastructure for tactical forces 
such as SOF detachments. This paints a stark reality: a high reliance on advanced 
communications technology is putting the U.S. military in a vulnerable position. 

Despite the aforementioned vulnerabilities, it would be foolhardy for the U.S. 
military to divest itself from advanced technology such as SATCOM, as technological 
superiority gives U.S. forces, and in particular SOF, a clear edge on today’s battlefield. 
However, redundant alternatives that build resiliency into existing space-based SATCOM 
architectures will help insulate against this critical vulnerability, while providing new 
options for communication techniques. Emerging technologies in miniature satellites and 
nanosatellites, for example, provide such alternatives.^ Recent advances in these 
technologies have created unprecedented access to space at much lower costs, leading to 
innovations and unique payloads. Furthermore, software-defined radios (SDR)—simple 
programmable radios—allow for low-cost experimentation and payload development. 

By utilizing nanosatellite technology in conjunction with SDRs, interesting 
possibilities with unique applications emerge. For the U.S. military, an SDR nanosatellite 
payload that builds redundant options for communication beyond traditional SATCOM 
would create much needed resiliency in the U.S. SATCOM architecture. Additionally, 
existing SATCOM systems generally do not support very high frequency (VHF) 
communication—transmissions from 30-300 MHz—yet most military forces rely heavily 


3 The term “nanosatellite” will heretofore be used to refer to small satellites with a wet mass of less 
than 10kg to include CubeSats and picosatellites. 
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upon VHF radios for line of sight (LOS) communication ^ Therefore, an SDR payload that 
augments existing VHF capabilities is quite valuable for military applications, potentially 
extending the range of VHF transmissions to SATCOM in lower orbits. While there are 
limitations for VHF transmissions supporting space-based communication, such as 
atmospheric scintillation, with enough power and the correct frequencies it is a viable 
alternative. With the current American way of war inexorably linked to space-based 
technology, and thus increasingly vulnerable, nanosatellites in low Earth orbit (LEO) 
provide interesting alternatives and redundancies that the United States should explore.^ If 
the U.S. military does not recognize the importance of protecting against its potential 
space-based weaknesses, it will find itself crippled in its hour of greatest need. 

A. PURPOSE AND SCOPE 

The purpose of this thesis is to illuminate the depth of the U.S. military’s reliance 
on space-based technology, understand the vulnerabilities this dependence creates, and 
design and test a payload to demonstrate the utility of using nanosatellites to mitigate these 
vulnerabilities. Developing a concept of operation (CONOP) for a constellation of 
nanosatellites serving as a VHP communications relay demonstrates the benefit of 
exploring nanosatellite applications. Subsequently building and testing a viable payload to 
prove the concept further emphasizes the utility of this emerging technology. Specifically, 
this thesis provides a feasible alternative to the U.S. military’s high reliance on space-based 
technology by developing a low-cost substitute for traditional SATCOM architectures via 
an SDR VHP nanosatellite relay: The Software-Assisted VHP Information Overhead 
Relay-CubeSat (SAVIOR-Cube). 


^ Gary D. Gordon and Walter L. Morgan, Principles of Satellite Communications (New York; John 
Wiley and Sons, Inc., 1993), 100. 

5 Low Earth orbit (LEO) is generally considered to be an orbit around the Earth with an altitude from 
approximately 150 km to 2,000 km above the Earth’s surface. 
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B. RESEARCH QUESTION 


Given the U.S. military’s dependence on space-based technology, how can 
nanosatellites be utilized as an alternative to traditional SATCOM architectures to protect 
against adversaries capable of exploiting U.S. vulnerabilities? 

C. UITERATURE REVIEW 

An examination of the modem U.S. military quickly reveals that the United States 
is highly reliant on space-based technology to function and is thus increasingly vulnerable 
to potential attacks.^ Examining the existing literature and theories on the cause of this 
high reliance, reviewing current SATCOM architectures, and understanding near-peer 
competitor anti-satellite capabilities identify the depth of the problem. The fundamentals 
of orbital mechanics as applied to emerging space technologies emphasize reasonable 
solutions that merit further research. Lastly, a brief examination of emerging nanosatellite 
applications and SDR technology highlights worthwhile solutions. Studying existing 
theories and methods helps in understanding the importance of finding an expedient 
solution to this critical vulnerability with a realistic safeguard. 

I. The Depth of the Prohlem 

Throughout history, military requirements and technological advances have been 
inexorably linked. Military necessities fostered by war and other crises led to competition 
between belligerents, and this competition frequently led to technological innovations that 
gave one side an edge on the battlefield. Often these innovations were in the form of 
advanced weapons such as nuclear bombs—new tools for killing.^ However, many 
scientific advances less macabre in nature also owe their discovery to military needs. 
During World War II, for example, the first modern computer, known as a Turing machine, 
was created by Alan Turing, a British intelligence officer, as a counter to the German 


^ Steven L. Bryant, “The Dangers of an Overreliance on Advanced Technology” (master’s thesis, 
National Defense University, 2011), 2. 

Antoine J Bousquet, The Scientific Way of Warfare: Order and Chaos on the Battlefields of 
Modernity (New York: Columbia University Press, 2009), 99. 
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Enigma machine.^ Communications technology has also seen many innovations thanks to 
military necessities. Electronic telegraphy, one of the first examples of humans sending 
information via electromagnetic signals, grew in prominence due to military forces using 
it as a means of communication. 9 American and Soviet competition during the Cold War 
led to the space race, which eventually resulted in the first man-made object orbiting the 
Earth—Sputnik. 10 Today, many advanced technologies, to include space-based 
technology, that developed out of necessity during wartime are now pervasive across the 
globe, enabling modern society. 

However, the interconnected relationship between military needs and technological 
innovations created a military culture, and in particular the culture of the U.S. military, 
highly reliant upon advanced technology. Accordingly, there are extensive debates on the 
U.S. military’s reliance on advanced technology. Critics argue that America used emerging 
technology to maintain an advantage over its adversary during the Cold War—the United 
Soviet Socialist Republic. H This created a culture of reliance on technology within the 
U.S. military since it was necessary for success. Some scholars make the case that necessity 
led to overreliance, and that the United States is now dangerously dependent on advanced 
technology. Though advanced technology gives the U.S. military a large advantage on the 
battlefield over its adversaries, it is becoming America’s Achilles heel for the United States 
is deficient in ample technological protections. Additionally, the problem is not easily 
solved because technology defines most aspects of U.S. military culture and doctrine. 

Yet, some scholars argue that the American military can undo this dependence, but 
to do so the United States must make sweeping changes to its current doctrine, training, 
and operational procedures.These recommended changes include properly adjusting 


^ Bousquet, 98. 

9 Bousquet, 95. 

Ih Bousquet, 134. 

Michael A VanPutte, Walking Wounded: Inside the U.S. Cyberwar Machine (CreateSpace 
Independent Publishing Platform, 2016), 3. 

VanPutte, 15. 

Bryant, “The Dangers of an Overreliance on Advanced Technology,” 60. 


5 



command structures to prevent overly centralized command and control as well as not 
allowing information and communication saturation to overwhelm decision makers. 
Other recommendations include updating U.S. military doctrine to address technological 
advances and to better incorporate the military in the procurement and training cycles for 
advanced technology. ^ 5 Lastly, the argument is made for resiliency and redundancy in 
technology, particularly for communications technology, to insulate against a loss of 
command and control. In other words, redundant communication systems help to reduce 
failure rates by building multiple pathways to the same target—a beneficial redundancy. 
Though these arguments do not directly address a high reliance on space-based technology, 
they are a consequence of the same symptoms. 

While much of the debate concerning the United States’ use of advanced 
technology does not focus on space-based systems, recent actions by China and Russia 
shed new light on space-based vulnerabilities. China, for example, tested its ability to 
destroy a satellite in LEO in 2007. General John Hyten, the Commander of U.S. Strategic 
Command, details the current danger China possesses as it continues to weaponize the 
space domain. He predicts that the same accuracy China demonstrated in LEO, could 
cripple the U.S. satellite infrastructure in geosynchronous orbit (GEO)—the orbit the 
United States relies on for much of its communication infrastructure. Similarly, some 
scholars believe that in preparation for a potential future conflict with the United States, 
China will strike American space infrastructure in the first move of this hypothetical 


Grauer, Commanding Military Power, 218. 

Bryant, “The Dangers of an Overreliance on Advanced Technology,” 56. 

David S. Alberts, John J. Garstka, Richard E. Hayes, and David A. Signori, “Understanding 
Information Age Warfare,” Command and Control Research Portal Publication Series (August 2001): 90. 

1^ Leo J. Blanken and Jason J. Lepore, “Unpacking the Various Meanings of Redundancy: From 
Refining the Concept to Military Planning,” Defense & Security Analysis, 28:4 (November 2012): 329. 

1^ “US Must Deter Chinese Aggression In Space And Be Ready For War,” Science World Report, 
February 9, 2017, http://www.scienceworldreport.eom/articles/56959/20170209/deter-chinese-aggression- 
space-ready-war-general.htm. 

1^ Science World Report. 
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conflict.^® By attacking what it sees as a U.S. critical vulnerability, China would gain 
relative superiority over the United States and cripple its military absent space-based 
technology. Though the United States is not blind to this vulnerability, the steps to protect 
against such attacks at the tactical and operational levels and the capability to operate in 
contingency scenarios absent space technology are woefully lacking. The stark reality is 
that America is perilously deficient in the self-defense of its space-based assets. 

Beyond such vulnerabilities, the U.S. military—and SOF in particular—have 
allowed satellites to shape its modern standard operating procedures. This has been 
especially evident during America’s Global War on Terrorism, as the United States’ use of 
space-based technology has exponentially increased in recent decades. According to Air 
Force Space Command, the U.S. military’s use of SATCOM increased from approximately 
10 Mbps per 5,000 service members in 1990 to approximately 150 Mbps in 2010—a 15- 
fold increase.22 In response to this surge in SATCOM demand, satellites now allow for 
real-time worldwide voice communication and access to data across all levels of 
classification in virtually any comer of the globe. For secure satellite voice 
communications, the U.S. military relies heavily upon the Mobile User Objective System 
(MUOS) constellation.23 This system allows U.S. forces to communicate via ultra high 
frequency (UHF) bands—transmissions from 0.3-3 GHz—to send real-time updates and 
plan complex operations using encrypted voice transmissions.24 

In addition to voice communication, the United States also uses SATCOM for 
various modes of data transmission, from sending simple reports to encrypted video¬ 
teleconferencing. The system that supports the majority of the U.S. military’s data needs 


2h Jim Sciutto, “US Military Readies for Next Frontier: Space War,” CNN, November 29, 2016, 
http://www.cnn.eom/2016/l 1/28/politics/space-war-us-military-preparations/index.html. 

21 Sciutto. 

22 Chuck Cynamon, “Military Satellite Communications,” Air Force Space Command, February 2010, 
accessed April 14, 2017, https://afcea-la.org/sites/afcea-la.org/files/AFCEA%20Brief%20Feb2010.pdf. 

23 Christopher K. Matassa, “.Comparing the Capabilities and Performance of the Ultra High Frequency 
Follow-On System with the Mobile User Objective System” (master’s thesis, Naval Postgraduate School, 
2011 ), 1 . 

24 Gordon, Principles of Satellite Communications, 100. 
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is the Wideband Global SATCOM (WGS) constellation. WGS operates in the super high 
frequency (SHF) band—transmissions from 3-30 GHz—and greatly enables the United 
States to conduct decentralized and technologically advanced operations while still 
maintaining modern connectivity. 25 SOFs especially take advantage of the modern 
connectivity provided by SATCOM. With a simple laptop, a small satellite dish, and the 
appropriate terminals, U.S. forces have access to troves of data, and commanders have 
unprecedented command and control despite geographic isolation. The capabilities 
provided by MUOS, WGS, and their predecessors have enabled the United States to spread 
SOF across the globe despite disparate lines of operations. SATCOM truly enables the new 
American way of war. 

Despite the state-of-the-art capabilities SATCOM provides, the U.S. military’s 
primary communications constellations are unfortunately not without vulnerabilities to 
both traditional and non-traditional anti-satellite technology. MUOS consists of five 
satellites in GEO residing at approximately 35,000 km above the Earth.26 WGS occupies 
the same orbital regime but with a few more satellites. Eor either constellation, a kinetic or 
cyber-attack or even a significant malfunction, would greatly limit the capacity of the 
systems. As an example, the loss of two MUOS satellites even with an on-orbit spare, 
would leave approximately a quarter of the Earth’s surface without coverage.27 Aside from 
traditional anti-satellite attacks, emerging technologies render these systems increasingly 
vulnerable. Directed energy lasers in development by both China and Russia will be 
capable of disabling and possibly destroying onboard computers and other hardware of 
satellites in orbit.28 The strength of a constellation in GEO is that the orbit’s high altitude 


25 “Wideband Global SATCOM Satellite,” U.S. Air Force, 2015, http;//www.af.mil/About-Us/Fact- 
Sheets/Display/Article/104512/wideband-global-satcom-satellite/. 

26 “Mobile User Objective System; Revolutionizing Secure Communications for Mobile Forces,” 
Lockheed Martin, accessed September 4, 2017, http://www.lockheedmartin.com/us/products/mobile-user- 
objective-system—muos-.html. 

27 Matassa, “.Comparing the Capabilities and Performance of the Ultra High Frequency Follow-On 
System with the Mobile User Objective System,” 21. 

28 Leonard David, “China, Russia Advancing Anti-Satellite Technology, U.S. Intelligence Chief 
Says,” Space.com, May 18, 2017, https://www.space.com/36891-space-war-anti-satellite-weapon- 
development. html. 
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provides a large coverage area with a relatively small number of satellites. However, the 
small number of satellites also make MUOS, WGS, and other GEO-based communication 
satellites vulnerable because the loss of one satellite would degrade the system’s capability 
by up to 20%.29 Akin to the U.S. military’s relationship with space-based technology, 
MUOS and WGS’ technological advantages are also their weaknesses. 

Fortunately, unique solutions may exist in the space domain due to emerging 
nanosatellite technology, but the U.S. military has yet to fully explore these options—it is 
still fighting with its heel exposed. Yet, the problem goes deeper than the U.S. military’s 
use of communication satellites. Modem banking, transportation, and communications 
infrastructure requires PNT data that Global Positioning System (GPS) satellites provide. 
A cyber or kinetic strike that disabled the existing GPS constellation would incapacitate 
modem American life—not just the U.S. military. China is cultivating the expertise to 
conduct such an attack as a precaution for a potential future conflict. 30 These examples 
validate the frightening hypothesis that the U.S. military and way of life are exceedingly 
vulnerable due to a high reliance on space-based technology. While these vulnerabilities 
exist across the spectrum of space-based technologies, this thesis focuses on SATCOM and 
on developing a potential alternative to traditional communication architectures. 

2. Emerging Solutions 

Though little research on potential solutions to this dependence exist, there are 
several unique hypotheses. One school of thought advocates for a return to terrestrial-based 
technologies. While the United States must maintain a proficiency in non-space-enabled 
techniques and technology, it cannot completely divest itself from the space domain. 
Furthermore, traditional terrestrial-based methods are generally proven and tested; the 
United States simply needs to maintain them as a contingency. Other hypothetical solutions 
involve the unique use of emerging technologies in the stratosphere, replicating the 


29 There are five MUOS satellites in orbit, four plus one on-orbit spare, with each representing 20% of 
the total system capacity. 

3h “US Must Deter Chinese Aggression In Space And Be Ready For War,” Science World Report. 
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functions provided by satellites at a much lower cost and ease of replacement. This idea, 
unfortunately, is largely untested and fraught with its own set of problems from 
environmental regulations to international law.^^ Just beyond the stratosphere and into 
LEO, however, some unique emerging space-based technologies provide more realistic 
solutions. 

Specifically, nanosatellites and other small satellite technologies may hold the key 
to safeguarding against a high reliance on space-based technology. With the advent of the 
cube satellite (CubeSat), nanosatellite technology has dramatically increased over the last 
eighteen years.^3 In 1999, two California Polytech State University professors originally 
developed the CubeSat as a standard around which to base nanosatellite technology. 34 
They intended to create a simple and low-cost form factor for designing CubeSats that 
would support experimentation and testing for graduate-level education.Generally, 
CubeSats are segmented into 10x10x10 cm cubes referred to as unit or a U. In other words, 
a lU CubeSat consists of one 10x10x10 cm cube, while a 2U cube is two 10x10x10 cm 
cubes.36 With this basic form factor of a U, CubeSats are easily customized to fit various 
nanosatellite payloads at a relatively low-cost and risk. Their simple and easily replicated 
design also makes CubeSats ideal for testing via high-altitude balloons (HAB) and other 
experimental techniques. Since the first launch of a CubeSat into space in 2003, the field 
has only grown, and the number in orbit around the Earth increases each year due to their 
simplicity and applicability for research and testing purposes.37 Consequently, the 
nanosatellite field today largely consists of CubeSats. 


31 Jason Koebler, “Solar-Powered Blimps Are the New Satellites,” Motherboard, March 6, 2014, 
https://motherboard.vice.com/en_us/article/solar-powered-blimps-are-the-new-satellites. 

32 Koebler. 

33 “CubeSats in Brief,” Innovative Solutions in Space, accessed December 25, 2017, 
https://www.isispace.nl/cubesats/. 

34 Innovative Solutions in Space. 

33 Form factor refers to the physical dimensions of an object: length, width, and height. 

36 Innovative Solutions in Space. 

37 Innovative Solutions in Space. 
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Similar to nanosatellites, SDR technology has also bloomed in the last few decades. 
SDRs are essentially programmable radios in which software replaces traditional hardware 
such as amplifiers.38 First developed in the 1980s, SDR technology exponentially grew in 
the 2000s in conjunction with advances in microchip technology.39 While military radios, 
cell phones, and other technologies have utilized SDR technology for some time, the advent 
of a program called GNU Radio, which allows for much easier and intuitive programming, 
opened access to SDR technology to those not literate in computer programming 
languages.^® It greatly opened the aperture for SDR experimentation. As such, amateur 
radio operators, students, and scientists use SDRs programmed with GNU radio for a 
myriad of purposes. In terms of designing the SAVIOR-Cube payload, SDRs and GNU 
Radio are critical for success. Absent this unique technology, a payload such as SAVIOR- 
Cube would be exponentially more difficult to design. 

3. A Brief Foray in Orbital Mechanics 

To truly understand the potential solutions nanosatellites and SDRs may provide, 
the fundamentals of the space environment require a basic understanding since that is 
where SAVIOR-Cube will hopefully operate one day. Fortunately, orbital mechanics, 
launch systems, and maneuvering in space are all thoroughly comprehended and widely 
tested. However, the basic constraints of the space domain merit a brief discussion prior to 
examining the potential of nanosatellites as a safeguard. A number of complex factors 
affect objects orbiting the Earth, ranging from space weather to gravity. Orbital 
perturbations, for example, cause a satellite to deviate from its orbit due to third body 
gravitational effects, the Earth’s oblateness, and numerous other factors."^! Eurthermore, 
due to the low altitude of EEO, satellites in this orbit are subjected to a large force of drag 
from the Earth’s atmosphere, in addition to about 80% of the force of gravity experienced 


38 “Software Defined Radio: Past, Present, and Future,” National Instruments, March 30, 2017, 
accessed December 2, 2017, http://www.ni.com/white-paper/53706/en/. 

39 National Instruments. 

National Instruments. 

Jerry Jon Sellers, et ah. Understanding Space: An Introduction to Astronautics, 3rd ed. (New York: 
McGraw-Hill Companies, 2005), 273. 
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on the Earth’s surface (altitude dependent)."^^ Space is also bursting with radiation and 
numerous anomalies that make the environment harsh for both manned and unmanned 
spaceflightMoreover, payloads are subject to the harshness of this environment and 
require intense radiation hardening, temperature survivability, and a multitude of other 
protections. Beyond the challenges of maintaining a constellation of LEO spacecraft, space 
launch is not trivial, and both launch and on-orbit maintenance budgets are complex in 
terms of money and fuel. These constraints demonstrate the multitude of complex 
challenges associated with the space environment. 

4. Utility of Nanosatellites 

Despite these limitations, the low-cost and small mass of nanosatellites still provide 
unique solutions for the vulnerability created by the U.S. reliance on space-based 
technology. Though they are a relatively new system for military applications, academic 
institutions and some aerospace companies widely use nanosatellites and CubeSats. 
Eurthermore, the field is swiftly growing, and the technology to build, launch, and maintain 
such technologies continues to improve rapidly.44 Their small size and quick production 
make them uniquely equipped to meet short-term, operationally responsive needs.45 While 
it would be difficult to replicate the capabilities provided by the massive MUOS or WGS 
satellites in a nanosatellite, the United States could specialize constellations to focus on 
specific capabilities to both build redundancy and serve as a safeguard in the event of an 
attack. Admittedly, LEO lacks many of the advantages provided by GEO for SATCOM, 
but the low-cost and quick production of nanosatellites make them an ideal solution for 
building resiliency. At the very least, the U.S. military would benefit from exploring these 
types of alternative options. 


42 Sellers, 134. 

43 Sellers, 85. 

44 Mark Holmes, “LEO: Two Generations Share Their Outlooks,” Via Satellite, February 2017, 
http://interactive.satellitetoday.com/via/february-2017/low-earth-orbit-two-generations-share-their- 
outlooks/. 

45 Anne Marinan and Kerri Cahoy, “From CubeSats to Constellations: Systems Design and 
Performance Analysis” (master’s thesis, Massachusetts Institute of Technology, 2013), 7. 
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Several existing studies regarding potential solutions to protect against America’s 
critical vulnerability in the space domain shed led on the utility of using nanosatellites. 
Specifically, the Navy’s Space and Naval Warfare Systems Command (SPAWAR) 
conducted a feasibility study regarding the use of small satellites in LEO to serve as a 
communications relay for VHP radios.This study built upon a concept developed by the 
U.S. Army Space and Missile Defense Command entitled the Army Resilient Global On- 
the-move SATCOM (ARGOS) System."^^ Both studies discuss the utility of using 
nanosatellites as a means to greatly increase the range and scope of non-SATCOM capable 
VHP radios. Each study suggests that by building a constellation of nanosatellites in PEO, 
the existing infrastructure of U.S. military ground-based radios would be exponentially 
more powerful. While both the SPAWAR and ARGOS studies require further research, 
they provide insight into forming a hypothesis for the way such a system may function in 
supporting U.S. military needs. SAVIOR-Cube intends to take these concepts one step 
further with a nanosatellite payload that consists of an SDR programmed as just such a 
VHP relay. 

D. METHODOLOGY AND APPROACH 

To fully develop a potential solution to this vulnerability, the depth of the problem 
requires understanding, which this chapter articulates throughout. However, designing a 
worthwhile payload requires further analysis and testing. Prior to developing SAVIOR- 
Cube, model constellations and CONOPs, discussed in Chapter II, highlight the payload’s 
applicability for the U.S. SOP today. Next, the trade space analysis in Chapter III highlights 
how examining the various hardware options contributes to an orderly design. Easily, 
laboratory tests ensure functionality and the results of a high-altitude balloon (HAB) flight, 
discussed in Chapter IV, simulate near-space conditions, short of an actual technology 
demonstration in PEO. By coupling a research-based methodology with scientific 
development, modeling, and testing, SAVIOR-Cube emerges as a redundant safeguard to 
traditional military SATCOM. 

Austin Mroczek, email message to author, May 23, 2017. 

Darin Lindon, email message to author, May 24, 2017. 


13 



1 . 


SAVIOR-Cube in Action 


Prior to an evaluation of the available SDR technology, potential applications for 
SAVIOR-Cube require analysis. First, a CONOP and operational view-1 (OV-1) for 
utilizing the payload highlights the applicability of SAVIOR-Cube for SOF detachments 
operating in remote areas, emphasizing the utility to today’s conflicts. Next, using the 
principles of orbital mechanics in conjunction with data from existing constellations, a 
model constellation built in Analytical Graphics Inc. Systems Tool Kit (STK) demonstrates 
coverage and potential orbital regimes. This simulation helps to determine whether or not 
the constellation provides the requisite coverage and whether or not it is a feasible concept. 
Finally, communications link budgets for the uplink and downlink from a VHF radio to the 
payload in orbit—calculated and modified for specific environmental effects, distances, 
and scenarios—provide insight into signal quality and build realistic grounding into this 
study. These steps demonstrate potential applications not just for SAVIOR-Cube, but also 
for nanosatellites writ large. 

2. Designing SAVIOR-Cube 

A concise and unbiased trade space analysis of payload hardware and testing 
conditions lays the foundation for experimentation. First, an analysis of the frequencies 
available for use within the VHF range helps to determine which SDRs and ancillary 
equipment support the objectives of this payload. Next, a comparison of man-portable 
radios that U.S. SOF currently use on today’s battlefield demonstrates options for the 
ground-based segment of testing. Examining low-cost and light-weight SDRs that can both 
receive and transmit in the VHF range outlines the heart of SAVIOR-Cube’s payload. 
Lastly, a similar comparison of available single board computers, amplifiers, and antennas 
completes the design. An analysis of these key variables is paramount to building a 
functioning and realistic payload. 

3. Testing SAVIOR-Cube 

With model constellations and CONOPs built, a prototype payload validates the 

applicability of nanosatellites with an SDR payload through testing in both the laboratory 

and on a HAB. The payload—an SDR with slight modifications—is designed to function 
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as a simple VHF voice relay capable of storing messages or executing real-time 
retransmissions that increase the effective range for otherwise distance-limited line-of- 
sight radios. Laboratory bench tests and further environmental tests allow for multiple 
iterations of testing under different simulated conditions. Next, the HAB flight 
demonstration of the SDR payload provides a reference for any capabilities that may be 
implemented on a future nanosatellite mission, while simultaneously testing the payload in 
a realistic near-space environment. In conjunction with ground forces simulated in a testing 
environment, the HAB platform replicates potential applications for nanosatellites in a 
denied-space environment. The results of the research and testing derived from this thesis 
demonstrate techniques and methods to defend against a critical vulnerability in the space 
domain. 

E. CHAPTER CONCLUSION 

Undoubtedly, the U.S. military is vulnerable due to its high reliance on space-based 
technology, and nanosatellites are a low-cost and expedient near-term solution to support 
U.S. forces that rely on satellites to wage the modem American way of war. Furthermore, 
they offer unique solutions in a degraded space environment as an alternative 
communication architecture. Specifically, a constellation of nanosatellites in LEO with a 
payload consisting of a simple software-defined VHF radio relay provides an 
unconventional method for satellite voice and data communication. An infrastmcture of 
space-based nanosatellite safeguards will help protect the U.S. military from its current 
vulnerabilities—precisely what SAVIOR-Cube aims to do. Prior to further discussing any 
CONOPs and experimental results for SAVIOR-Cube, Chapter II analyzes its applicability 
and feasibility. 


15 



THIS PAGE INTENTIONALLY LEET BLANK 


16 



II. SAVIOR-CUBE IN ACTION 


As the action armof U.S. foreign policy, U.S. Special Operations Forces (SOF) are 
spread across the globe and thus rely highly upon satellite communication (SATCOM) for 
command and control, the vulnerability of which Chapter I covers. Solutions for this 
vulnerability derived from emerging technology in nanosatellites merit further exploration. 
One example is a nanosatellite software-defined radio (SDR) very high frequency (VHF) 
relay, such as the Software Assisted VHF Information Overhead Relay-CubeSat 
(SAVIOR-Cube). This chapter focuses on the applicability of SAVIOR-Cube and 
demonstrates that nanosatellites may help build resiliency into the U.S. SATCOM 
infrastructure. First, a credible scenario in which a special operations detachment could 
benefit from SAVIOR-Cube demonstrates its applicability for U.S. SOF. Next, a model 
constellation validates that nanosatellites in low Earth orbit (LEO) can feasibly support 
decentralized SATCOM. Lastly, a communication link budget shows that a VHE link from 
LEO will have a positive margin; it demonstrates that it is a realistic solution. Most 
importantly, the analysis in this chapter illustrates that SAVIOR-Cube has both realistic 
and direct applications for U.S. SOL across the globe. 

A. A WORLD WITHOUT SAVIOR-CUBE 

An illustrative fictional example of SAVIOR-Cube in action shows the potential 
applicability for U.S. forces in the field. As Chapter I illustrates, the decentralized nature 
of many special operations leads to large geographic distances between units, requiring 
SOL to rely upon SATCOM for much of their communication needs. The following 
scenario illustrates what a SOL detachment could face in an emergency scenario absent 
SATCOM capabilities. More specifically, the scenario shows the startling vulnerability 
U.S. forces may find themselves in absent SATCOM capabilities on the battlefield. It 
demonstrates the role SAVIOR-Cube could play in building resiliency into U.S. space- 
based infrastructure. 

Special Lorces Operational Detachment-Alpha (SLOD-A) 0425 is on a routine 
mission to the remote village of Amaloul—located in the Tahoua region of the sub- 
Saharan country of Niger—to provide medical support to the otherwise isolated 
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village. They are approximately 400 km northeast of their higher headquarters in 
the Nigerien capital of Niamey; this large geographic distance forces the 
detachment to use SATCOM for voice and data communication. On today’s 
mission, they are relying upon Harris PRC 117 radios for SATCOM with Niamey 
and Harris PRC 152 radios for team internal line of sight (LOS) communication. 
Despite the peaceful nature of the mission—medical support—the prevalence of 
violent extremist organizations in the area, such as A1 Qaeda in the Islamic 
Maghreb (AQIM), endangers the detachment. 

As SFOD-A 0425 is traveling north along a sandy desert road from Tahoua City to 
Amaloul, they notice movement to the east of road, but civilian traffic in the area 
is not uncommon. Yet, the possibility of a catastrophic attack by AQIM puts the 
detachment on edge. Their intuition is not misplaced, for the movement to the east 
increases. Before they know it, a small improvised explosive device disables the 
lead vehicle and a massive force numbering close to one hundred fighters ambushes 
the detachment. The ferocity of the initial attack disables all of the detachment’s 
vehicles, trapping them in the kill zone. SFOD-A 0425 relies upon their extensive 
training and counterattacks the AQIM force to provide enough suppressive fire for 
the detachment to break contact to the west. 

Unfortunately, the initial violent attack that disables the detachment’s vehicles also 
destroys the SATCOM capable PRC 117 radios. SFOD-A 0425 does not have a 
form of SATCOM and is unable to call for air support or reinforcements—they are 
on their own. The detachment thus executes their evasion plan: a plan to evade 
enemy forces and safely reach their headquarters in Niamey. The large distance and 
harsh desert terrain between the Tahoua region and Niamey makes for a rough and 
perilous journey that takes days on foot. Due to a lack of SATCOM, the detachment 
is absent the ability to communicate with friendly forces and request much needed 
supplies or exfiltration. Furthermore, the headquarters in Niamey and U.S. Special 
Operations Command Africa (SOCAF) in Stuttgart, Germany is helpless to support 
the detachment. 

In an effort to aid the detachment, SOCAF flies manned and unmanned aircraft and 
uses remote sensing satellites to locate SFOD-A 0425. After three long days of 
searching overhead and evading AQIM forces on the ground, a tired, dehydrated, 
and hungry detachment is located in the desert, moving west toward Niamey. 
SOCAF arranges for a safe exfiltration, and the exhausted detachment is returned 
to safety. 

While this vignette raises a number of questions, the key question as it relates to 
this study is: what if the detachment had a resilient form of SATCOM that enabled their 
VHF radios to communicate with satellites overhead? With SAVIOR-Cube overhead, 
SFOD-A 0425 could have requested much needed support from Niamey and SOCAF. 
Furthermore, imagine if there had been constellation of SAVIOR-Cube nanosatellites that 
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provides daily coverage to every place on the planet at least twice a day for a minimum of 
a two-minute window (similar to what many remote sensing constellations provide from 
LEO). If this hypothetical constellation was flying an SDR as its payload, serving as a VHP 
radio relay, it could have been useful for the evading detachment, providing SATCOM to 
the detachment despite their lack of SATCOM-capable radios. With accurate two-line 
element (TEE) data available for satellites—predicating orbits months and years in 
advance—the detachment could have built the coverage windows of this constellation into 
their evasion plan. If they knew one of the satellites would have been overhead a specific 
location along their planned evasion route, they could have traveled to a known coverage 
location, established a safe site, and waited for coverage. During the coverage window, the 
detachment could have used simple VHP EOS radios to broadcast a message containing 
their location, plan of action, and status to any friendly forces also within range of the 
satellite during their transmission. While this would have only increased the range of the 
radio from tens to hundreds of kilometers, it would have still greatly expanded their VHP 
communication range. 

In addition to a real-time SATCOM relay, if the payload would have been capable 
of recording and forwarding the detachment’s voice transmissions, the distance limitation 
would have been moot. The payload would have recorded the detachment’s transmission 
and retransmitted it on a loop, eventually reaching the headquarters in Niamey or SOCAP 
in Stuttgart, Germany. Thus, rather than evading without command and control from their 
higher headquarters for 375 km, the detachment could have sent and received transmissions 
to a simple nanosatellite in PEG and coordinated a much quicker exfiltration—a low-cost 
solution to a complex problem. Pigure 1 depicts an operational view-1 (OV-1) for 
SAVIOR-Cube as it relates to this vignette. 
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;AVIOR-Cube 


SAVIOR-Cube will operate a software defined radio 
(SDR) payload from low Earth orbit (LEO) that serves 
as a communications relay for very high frequency 
(VHP) voice and basic data transmissions normally 
limited to line of sight communications. Special 
operations detachments that are geographically 
separated from their adjacent units or higher 
headquarters can utilize SAVIOR-Cube to send 
transmissions limited by line of sight and VHP 
restrictions. With accurate satellite and constellation 
position data, detachments can plan contingencies 
such as evasion plans around SAVIOR-Cube 
coverage windows, increasing communication options 
in emergency scenarios and potentially saving the 
lives of U.S. and allied forces. 


Figure 1. SAVIOR-Cube Operational View-1 


This fictional yet realistic vignette in Niger highlights SAVIOR-Cube’s 
applicability for U.S. SOF across the globe. Furthermore, the potential applications for a 
VHF relay across the U.S. military are numerous. Aside from an evasion scenario, 
SAVIOR-Cube could also support communication in an unconventional warfare campaign 
such as the U.S. campaign to overthrow the Taliban across Afghanistan in late 2001. 
Additionally, it could provide SATCOM to forces lacking UHF capabilities due to resource 
constraints or support forces in a degraded space domain absent traditional SATCOM. 
Undoubtedly, there are many applications for a payload that increase U.S. SATCOM 
capabilities via resilient and unconventional approaches beyond traditional SATCOM. 

B. SAVIOR-CUBE IN ORBIT 

Simply because there are applications for SAVIOR-Cube to support U.S. SOF does 
not mean the concept of a VHF radio in LEO is feasible to implement. For example, 24- 
hour global coverage—the gold standard for SATCOM—would require a massive 
constellation from LEO. The Iridium satellite constellation, for example, accomplishes this 
amount of coverage with 66 satellites from an altitude of approximately 700 km and an 
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inclination of approximately 86.4°."*'^ This constellation provides continuous global 
satellite phone coverage from LEO. However, an architecture at a lower altitude would 
entail a larger constellation to provide such coverage—potentially demanding over a 
hundred satellites. These limitations of a VHP link complicate the use of VHP for 
SATCOM. Yet, as the SAVIOR-Cube scenario conveys, SOP could benefit from a 
constellation that provides coverage long enough for simple voice transmissions 
(approximately two minutes) at least twice each day. Portunately, if utilizing nanosatellites 
such a constellation is not beyond reasonable. 

Thus, to build a nanosatellite constellation for SAVIOR-Cube, this type of global 
coverage is the goal. Purther aiming for global coverage to include the poles, a polar orbit 
with streets of coverage is the most reasonable method for designing such a constellation. 
Polar orbits inclined at approximately 90° orbit the Earth from the North Pole to the South 
Pole, moving north to south above the Earth at a right angle to the equator.49 Pigure 2 
depicts a 90° orbit with a satellite crossing over the north pole, illustrating this concept. 



Pigure 2. Polar Orbit 


“Iridium Next,” eoPortal Directory, accessed 03 December 2017, https://directory.eoportal.org/web/ 
eoportal/satellite-missions/i/iridium-next. 

“^9 Sellers, Understanding Space: An Introduction to Astronautics, 157. 
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This orbital pattern allows a satellite plane to provide equitable coverage to the 
entire surface of the Earth rather than focusing on the equator or targeting a specific area 
such as a U.S. combatant command (COCOM). For these reasons, a polar orbit is a sound 
starting point for designing a SAVIOR-Cube constellation that aims to provide frequent 
revisit times across the globe. 

Furthermore, in order to equalize the coverage as much as possible, streets of 
coverage constellations are best. 50 Streets of coverage constellations include multiple 
planes of continuous bands of satellites spread equally around the Earth. They allow for 
frequent revisit time and predictable coverage; it is the most efficient way to maximize 
global coverage.51 A polar inclination and a streets of coverage design provide a baseline 
for designing a SAVIOR-Cube constellation, an example of which Figure 3 depicts. 



Figure 3. Polar Streets of Coverage Design 


Though orbital mechanics—the physical laws that govern orbits—are incredibly 
complex, useful tools such as the Analytic Graphic Inc.’s (AGI) Systems Tool Kit (STK) 


5h Olivier L. de Week, Uriel Scialom, and Afreen Siddiqi, “Optimal Reconfiguration of Satellite 
Constellations with the Auction Algorith,” Acta Astronautica 62 (February 2008): 113. 

51 Week, 113. 
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provide a means to model constellations. STK’s tools provide numerous options for 
constellation modeling, which can be applied to a baseline SAVIOR-Cube constellation. 
Rather than dissecting all of the classical orbital elements for the constellation, a few basic 
elements provide the details required to understand the orbital regime. Specifically, the 
inclination, altitude, number of orbital planes, and number of satellites per plane reveal the 
key orbital elements for designing this constellation. 

Examining Planet Labs’—an innovative small satellite company—Sky Sat 
constellation provides a reference for designing a SAVIOR-Cube constellation due to the 
orbit’s altitude and inclination. While Sky Sat is a remote sensing imagery constellation, 
its orbital regime is similar to a constellation that could support SAVIOR-Cube’s mission. 
Sky Sat’s constellation consists of thirteen satellites at an approximate altitude of 500 km 
and a sun-synchronous orbit of 97.8°, similar to a polar orbit.52 with this small 
constellation and relatively low altitude. Sky Sat provides a new image of every place on 
the Earth’s surface multiple times a day.^^ To shorten the distance for the communication 
link and simplify the inclination for analytical purposes, SAVIOR-Cube utilizes an altitude 
of 450 km and an exact polar orbit of 90°. Applying this concept to a streets of coverage 
design at 450 km and a 90° inclination, six planes of four satellites offer a robust amount 
of coverage with twenty-four total satellites. Eigure 4 graphically depicts such a 
constellation and Table 1 summarizes the orbital parameters. 


Table 1. SAVIOR-Cube Orbital Parameters 


Altitude 

450 km 

Inclination 

90° 

Number of Planes 

6 planes 

Satellites per Plane 

4 satellites 


“SkySat Constellation of Terra Bella - Formerly SkySat Imaging Program of Skybox Imaging,” 
eoPortal Directory, accessed February 28, 2018, https://directory.eoportal.org/web/eoportal/satellite- 
mis sions/s/skys at. 

eoPortal Directory. 
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Figure 4. SAVIOR-Cube Constellation 


In terms of global coverage, a six-plane four-satellite polar constellation does not 
disappoint. However, there are constraints on the amount of coverage it provides. For 
example, terrain, elevation, urban areas, and other factors surrounding a ground-based user 
will limit a signal’s ability to reach a satellite in orbit. Furthermore, as a satellite reaches 
the limit of the horizon, its coverage will eventually degrade beyond repair. A standard 
estimate to the limit of coverage and elevation angles for maritime VHF is 5-10°.Yet to 
account for the aforementioned terrain-based constraints and to provide conservative 
estimates of this constellation’s coverage, a minimum elevation angle of 20° provides a 
more realistic estimate of coverage definitions. With this constraint, the global SAVIOR- 
Cube mean access duration—the average amount of time each coverage window lasts—is 
approximately four minutes. The mean revisit time—the average amount of time between 
satellite coverage windows—is approximately twenty-one minutes. In other words, on 
average, every place on the Earth’s surface will have approximately four minutes of 
coverage every twenty-one minutes; this constellation could support a resilient form of 
SATCOM. 

However, the SAVIOR-Cube constellation coverage is not equal across all 
latitudes. Due to the shape and rotation of the Earth, the Earth rotates fastest at the equator 

Lars Loge, “Arctic Communications System Utilizing Satellites in Highly Elliptical Orbits” 
(doctoral thesis, Norwegian University of Science and Technology, 2013), 62. 
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and slowest at the poles. Therefore, olar regions will have more coverage because the 
satellite will dwell longer over those regions due to the lower velocity of the Earth’s 
rotation near the poles. Additionally, as a satellite descends and ascends over the North and 
South Poles, the coverage over those regions will be longer due to the shape of the Earth 
in respect to the 90° plane.^^ Regardless of these differences in coverage across the Earth, 
the coverage definitions globally are sound. Table 2 breaks down STK-based analysis that 
provides the minimum, maximum, and mean access duration and revisit time globally and 
for each of the U.S. COCOMs, providing a comparison of coverage across the globe. 


Table 2. Global Coverage 


Access Duration 
Revisit Time 

Access Duration 
Revisit Time 

Access Duration 
Revisit Time 

Access Duration 
Revisit Time 

Access Duration 
Revisit Time 

Access Duration 
Revisit Time 

Access Duration 
Revisit Time 


Minimum (minutes) Maximum (minutes) 

Global 

4.00 5.68 

1.44 29.9 

U.S. Africa Command (AFRICOM) 

4.05 4.52 

5.04 29.9 

U.S. Central Command (CENTCOM) 

4.19 4.53 

15.3 29.9 

U.S. European Command (EUCOM) 

4.10 4.53 

2.40 27.1 

U.S. Northern Command (NORTHCOM) 

4.13 4.51 

2.72 28.4 

U.S. Pacific Command (PACOM) 

4.06 4.51 

2.68 29.2 

U.S. Southern Command (SOUTHCOM) 

4.08 4.48 

2.52 29.2 


Mean (minutes) 

4.35 

21.1 

4.32 
23.9 

4.35 

23.6 

4.37 

14.6 

4.35 

17.3 

4.33 
22.1 

4.33 

23.0 


Eor SAVIOR-Cube, STK helps in not only building constellations, but it also 
determines the coverage over the two locations in the scenario: Niamey and Tahoua, Niger. 
While COCOM and global coverage definitions are useful, more specific locations provide 


Sellers, Understanding Space: An Introduction to Astronautics, 157. 
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more realistic expectations of coverage. Table 3 depicts the minimum, maximum, and 
mean access duration and revisit time for all of Niger, Niamey, and Tahoua separately, 
while Figure 5 graphically depicts simultaneous coverage for Niamey and Tahoua. 


Table 3. Niger Coverage 



Minimum (minutes) 

Maximum (minutes) 

Mean (minutes) 

Niger 

Access Duration 

0.199 


5.51 

4.34 

Revisit Time 

n/a 


73.4 

24.3 

Tahoua 

Access Duration 

1.01 


5.48 

4.17 

Revisit Time 

n/a 


58.7 

28.9 

Niamey 

Access Duration 

0.901 


5.49 

4.20 

Revisit Time 

n/a 


58.8 

29.7 



Figure 5. SAVIOR-Cube over Niger 


As Table 3 confirms, both Niamey and Tahoua have approximately four minutes 
of coverage every twenty-nine minutes—a reasonable amount of coverage for the service 
SAVIOR-Cube aims to provide. 

This example constellation for SAVIOR-Cube and the subsequent analysis 
demonstrate the type of constellation required for a VHF nanosatellite relay and the 
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coverage it would provide. Furthermore, accurate TLE data for the constellation would 
allow a SOF detachment or any ground-based user to plan missions around coverage 
windows. Absent access to TLE data, the frequent revisit time of the SAVIOR-Cube 
constellation affords enough predictability for approximation. While future analysis and 
modeling in STK would highlight additional constellations that support SAVIOR-Cube’s 
mission, this constellation provides a baseline from which to design and validate initial 
testing. 


C. CALCULATING SAVIOR-CUBE 

While a concept of operations (CONOP) provides relevance to this payload and a 
model constellation further solidifies SAVIOR-Cube as feasible, a communication link 
budget adds additional weight to the concept; it confirms that it is a realistic hypothesis. In 
terms of a communication link budget, the key components are the uplink and the 
downlink. The uplink is the transmission from a ground-based radio to a satellite in orbit; 
the downlink is the transmission from a satellite in orbit to a separate ground-based radio. 
Figure 6 illustrates this concept, with a communication link connecting two ground-based 
radios to a satellite overhead. 



Beyond IJne of Sight 


VHF Radios 


SATCOM Degraded 
Environment 


> Hr Nanosatellite Relav 


Figure 6. Satellite Uplink and Downlink 
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Though there are constraints to using VHP to communicate from space, these 
challenges are not insurmountable, as discussed further in Chapter III. With enough power 
and amplification, for example, VHP transmissions tuned to the appropriate frequencies 
can successfully penetrate the Earth’s atmosphere. In fact, the International Space Station’s 
amateur radio program attests to this fact, sending and receiving transmissions from LEO 
to ground-based users in VHE.^® A worthwhile analog for what SAVIOR-Cube aims to 
provide. 

However, in order to dissect the specific VHE link budget for SAVIOR-Cube, 
certain parameters require clarification to understand the mathematics, starting with the 
downlink. Eirst, the power for the ground terminal and the receive threshold are based on 
Harris Radio’s PRC 117 radio—the radio of choice for many U.S. SOE operating across 
the globe. The maximum transmit power for this radio is 10 W (40 dBm), and the receive 
threshold—the weakest signal the radio is rated to receive—is -118 dBm.^^ Eor the ground 
antenna, the gain is 2 dBi based on standard gain parameters for Harris VHE antennas. 
Next, for the downlink from SAVIOR-Cube, the payload is assumed to have 1 W (30 dBm) 
of transmit power—not unreasonable for a CubeSat with the appropriate electrical power 
system (EPS). The receive threshold for an SDR in orbit is arbitrarily set at -95 dBm, since 
the actual margin is unknown. Nevertheless, -95 dBm is a reasonable margin for VHP 
communications. Similar to the ground antenna, the SAVIOR-Cube antenna gain is 2 dBi. 
In order to add realistic loss into the equation, transmitter losses are 2 dB; miscellaneous 
losses are 5 dB; and receiver losses are 2 dB. Given this scenario, an altitude of 450 km is 
used for free-space path loss calculations and other link budget factors, based upon the 
model SAVIOR-Cube constellation. With that information. Equation 1 easily provides 
power received.58 

Pr = Pt + Gt- Lt- Lfs -Lm + Gr-Lr (Equation 1) 


“Contact the ISS,” Amateur Radio on the International Space Station, accessed November 3, 2017, 
http://www.ariss.org/contact-the-iss.html. 

“Harris III AN/PRC-117G(V)1(C),” Harris Corporation, 2017, https://www.harris.com/sites/ 
default/files/downloads/solutions/an-prc-117g-multiband-networking-manpack-radio-datasheet.pdf. 

Gordon, Principles of Satellite Communications, 43. 
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In this equation, Pr is the power received, Gt is the gain of the transmitter, Lt is 
transmitter losses, Lfs is free-space path loss, Lm represents miscellaneous losses, Gr is the 
receiver gain, and finally Lr is receiver losses. Each of these variables is in decibels to allow 
for easy computing using simple addition and subtraction. Furthermore, free-space path 
loss, the reduction of an electromagnetic signal’s strength as it travels over distance, is 
determined using Equation 2 .^^ 

Lfs = 20logioS + lOlogiof + 92.45 (Equation 2) 

Efs once again represents free-space path loss, S represents the distance or range 
from a ground-based radio to the satellite in kilometers, and / is the frequency in gigahertz. 
The other values in the equation convert the free-space path loss values into decibels. Table 
4 summarizes the downlink budget for SAVIOR-Cube based on the orbital parameters 
outlined in Table 1. 


Table 4. Downlink Budget 


Term 

Variable 

Value 

Transmitter Power 

P, 

30.0 dBm 

Transmitter Gain 

Gt 

2.00 dBi 

Transmitter Losses 

Lt 

2.00 dB 

Free-Space Path Loss 

Lfs 

128.7 dB 

Miscellaneous Losses 

Lm 

5dB 

Receiver Gain 

a 

2 dBi 

Receiver Losses 

Lt 

2dB 

Power Received 

Pr 

-103.7 dBm 

Receive Threshold 

n/a 

-118 dBm 

Receive Margin 

n/a 

14.3 dBm 


As stated previously, the minimum receive threshold for the radio in this scenario 
is -118 dBm. With a calculated received power of -103.68 dBm, there is a margin of 14.32 
dBm. Given that the link will close with the lower 30 dBm transmit power of the satellite 
payload, the link should also close with the 40 dBm transmit power of the radio on the 
ground. However, the estimated receive threshold for the SDR is a bit smaller than the 


Gordon, 39. 
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margin for the Harris PRC 117 radio. Thus, for thoroughness, Table 5 calculates the uplink 
budget. 


Table 5. Uplink Budget 


Term 

Variable 

Value 

Transmitter Power 

P, 

40.0 dBm 

Transmitter Gain 

Gt 

2.00 dBi 

Transmitter Losses 

L, 

2.00 dB 

Free-Space Path Loss 

Lfs 

128.7 dB 

Miscellaneous Losses 

Lm 

5.00 dB 

Receiver Gain 

Gr 

2.00 dBi 

Receiver Losses 

Lr 

2.00 dB 

Power Received 

Pr 

-93.7 dBm 

Receive Threshold 

n/a 

-95.0 dBm 

Receive Margin 

n/a 

1.30 dBm 


With an estimated receive margin of -95 dBm and an uplink signal strength of - 
93.68 dBm, there is a slight margin of 1.32 dBm. Yet, -95 dBm is a hypothetical threshold 
for a SAVIOR-Cube payload. If fully designed and tested for spaceflight, a payload could 
be built with efficient antennas, robust low noise amplifiers, and adequate receive margins, 
similar to how the PRC 117 is designed for the ground segment. Consequently, the two link 
budgets demonstrate that the concept of a VHP radio relay in LEO is theoretically possible 
for both the uplink and the downlink—the communications link will close. 

While these link budgets suffice for the purposes of this thesis, future research and 
testing will need to account for certain constraints beyond the scope of this thesis. For 
example, antenna angles for VHP dipole antennas as well as changes to the Earth’s 
atmosphere throughout the day may add additional complexity to the link budget. 
Furthermore, a value of 450 km when calculating free-space path loss—^based on the 
proposed SAVIOR-Cube altitude—does not account for slant range. The altitude of 
SAVIOR-Cube, used to compute the downlink and uplink margins, accounts for the 
satellite range at nadir. In other words, when the satellite is directly overhead. Slant range, 
however, is the actual range between a radio on the ground and the satellite overhead.^® It 


Gordon, 10. 
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accounts for actual distance between the two radiating antennas. Thus, slant range will 
increase the free-space path loss. Yet, for this initial SAVIOR-Cube concept and test, the 
positive margins in the downlink and uplink budgets suffice for demonstrating that a VHP 
communications link will realistically close from LEO. 

D. CHAPTER CONCLUSION 

U.S. SOF across the globe would benefit greatly from a resilient form of 
communications that expands current SATCOM capabilities, such as SAVIOR-Cube: a 
VHP nanosatellite relay. The focus of this chapter demonstrates that a VHP nanosatellite 
relay is applicable, feasible, and realistic for U.S. forces today. A concept of operations for 
SAVIOR-Cube supporting SOF in the field demonstrates applicability, while a model 
SAVIOR-Cube constellation depicts its feasibility. Pastly, a communication link budget 
proves that SAVIOR-Cube is a realistic concept. To truly validate the concept, further 
testing is required in both the lab environment and the near-space environment, the results 
of which are discussed in Chapter IV. Prior to discussing test results, however, the next 
chapter contains a detailed trade space analysis for building a prototype payload for testing 
purposes. 
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III. DESIGNING SAVIOR-CUBE 


Today, space technology greatly enables the modern American way of war—quick, 
decisive, and decentralized operations—and U.S. Special Operations Forces (SOF) 
particularly rely upon satellite communications (SATCOM) for all facets of operations. 
While Chapter I discusses the causes and dangers of this reliance. Chapter II demonstrates 
that emerging technology in nanosatellites provides applicable, feasible, and realistic 
solutions to this critical vulnerability, such as a very high frequency (VHF) software- 
defined radio (SDR) relay. Analysis regarding the results of testing such a prototype 
payload validates the feasibility of this concept, which is further discussed in Chapter IV. 
In this chapter, however, a trade space analysis of the frequency spectrum, man-portable 
radios, SDRs, single-board computers, antennas, and amplifiers available for testing on the 
high-altitude balloon (HAB) platform lays the foundation for experimentation. A thorough 
trade space analysis, a comparison of the hardware and resources available for a design, 
compares the relative advantages and disadvantages of various components. In this case, it 
defines the requirements for building an engineering design unit (EDU) for the Software- 
Assisted VHF Information Overhead Relay-CubeSat (SAVIOR-Cube) payload in a HAB. 
While the payload design will change slightly if installed on a nanosatellite for space flight, 
this trade space analysis ensures the payload is not only adequately designed for success, 
but it also lays the foundation for future iterations of testing—both terrestrial and space- 
based. 

A. WHAT IS SAVIOR-CUBE? 

While this chapter’s trade space analysis compares the best hardware for designing 
an EDU for SAVIOR-Cube, a general description of the payload itself first provides clarity. 
Eirst and foremost, the heart of the payload is an SDR that receives, transmits, and 
modulates radio signals. Next, the SDR requires a payload computer for processing and 
commanding—it needs a driver. To receive and transmit electromagnetic signals, the SDR 
requires two external antennas: a receive antenna (Rx) and a transmit antenna (Tx). In other 
words, it must be a full-duplex SDR, capable of simultaneously receiving and transmitting 
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electromagnetic signals from two separate antennae. Lastly, an amplifier attached to the 
transmit antenna ensures the SDR transmits a strong signal. These four basic pieces of 
hardware (SDR, computer, antenna, and amplifier) are the building blocks for SAVIOR- 
Cube. Figure 7 depicts a signal flow diagram of a rudimentary payload. 


f -\ 

Payload 
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Software 
Defined Radio 



Incoming 

Signal 


Outgoing 
, Signal 


Figure 7. Rudimentary SAVIOR-Cube Design 


As Figure 7 depicts, the receive antenna receives signals transmitted in the 
frequency to which the payload is tuned. From the receive antenna, the SDR receives and 
modulates the received signal from analog to digital. With the help of the payload 
computer, the SDR filters and appropriately modifies the signal per software parameters. 
Once modified, the payload computer commands the SDR to demodulate the signal from 
digital to analog and transmit the signal to the amplifier, increasing the signal strength. 
Beyond the amplifier, the signal travels to the transmit antenna which radiates the signal 
from SAVIOR-Cube to its intended target. Akin to traditional communication satellites, it 
receives a signal and retransmits it on a different frequency to ground-based users. Simply 
put, SAVIOR-Cube is a bent-pipe VHF relay. 

B. WHAT IS THE FREQUENCY CUBE? 

Discussing any specific hardware for building the SAVIOR-Cube payload first 
requires a clear understanding of the frequency spectrums available for testing. There are 
various naming conventions for delineating bands within the electromagnetic spectrum that 
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support voice and data communication via radio waves. This thesis, however, utilizes the 
International Telecommunication Union convention of naming frequency ranges from very 
low frequency (VLF) at the low end of the spectrum to extremely high frequency (EHF) at 
the high end.^^ The terms VLF, low frequency (LF), and medium frequency (MF) refer to 
the range of frequencies from 3 kHz to 3 MHz, but they are below the frequencies relevant 
to the experimentation for this thesis.High frequency (HF), which ranges from 3-30 
MHz, supports many amateur and maritime radio communications.Military and civilian 
radios widely use VHF, transmissions from 30-300 MHz, for line of sight (LOS) 
communications.Ultra high frequency (UHL), which is from 0.3-3 GHz, and super high 
frequency (SHL), which is from 3-30 GHz, primarily support SATCOM voice and data 
transmissions.Lastly, extremely high frequency (EHL) supports limited SATCOM 
transmissions, but certain constraints such as nuclear blackouts affect it less.66 This naming 
convention provides a basic method for delineating which frequencies support specific 
functions—a useful tool for this study. Lor ease. Table 6 further breaks down these bands. 


Table 6. Lrequency Bands67 


Frequency Spectrum 

Designation 

Acronym 

3-30 kHz 

Very Low Frequency 

VLF 

30-300 kHz 

Low Frequency 

LF 

0.3-3 MHz 

Medium Frequency 

MF 

3-30 MHz 

High Frequency 

HF 

30-300 MHz 

Very High Frequency 

VHF 

0.3-3 GHz 

Ultra High Frequency 

UHF 

3-30 GHz 

Super High Frequency 

SHF 

30-300 GHz 

Extremely High Frequency 

EHF 


61 Gordon, Principles of Satellite Communications, 100. 

62 Gordon, 100. 

63 Gordon, 100. 

64 Gordon, 100. 

65 Gordon, 100. 

66 “The Army Satellite Communications Architecture Book,” (Fort Gordon, GA: U.S. Army Signal 
Center of Excellence, 2013), 2-25. 

62 Gordon, Principles of Satellite Communications, 100. 
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While UHF bands are used for the majority of SATCOM voice communication— 
from the commercial Iridium satellite phone system in low Earth orbit (LEO) to the 
massive military communication satellites in geosynchronous orbit (GEO)—VHE is the 
band of choice for military LOS communications. However, for most military SATCOM, 
VHE is typically insufficient due to a number of constraints. Eirst, VHE communications 
in the lower end of the frequency spectrum typically reflect off the ionosphere and never 
reach satellites in orbit.68 Second, any VHE signals that penetrate the Earth’s dense 
atmosphere will have a difficult time reaching satellites beyond LEO due to exponential 
free-space path loss—signal attenuation caused by the distance a signal travels from 
transmitter to receiver.69 Einally, because of the long wavelength of radio waves in the 
VHE spectrum, the antenna size, both on the ground and in orbit, will be much larger than 
an antenna in the UHE spectrum.^® Antenna size is a very important factor given that man- 
portable radios rely upon VHE for voice communications. With the small size and mass of 
the CubeSat form factor, a large antenna may be problematic if the intent is to keep 
SAVIOR-Cube relatively small. These constraints, though not insurmountable given some 
ingenuity and access to emerging technologies, have limited the utility of VHE testing for 
SATCOM to date. 

Since most LOS radio communication utilizes VHE frequencies, the U.S. military 
has a massive inventory of VHE capable radios as a result. These range from rudimentary 
Vietnam-era radios to state-of-the-art radios used by U.S. SOE across the globe today. In 
terms of the U.S. military, VHE voice communications are traditionally conducted between 
30 MHz and 250 MHz depending on the radio. Eurthermore, the military refers to the range 
from 30 MHz to 90 MHz as the Single Channel Ground and Airborne Radio System 
(SINCGARS), a common radio network that has supported U.S. military operations for 
decades. Thus, almost all VHE LOS radios have a SINCGARS mode, but modern military 


U.S. Army Signal Center of Excellence, “The Army Satellite Communications Architecture Book,” 

2-23. 

^9 Gordon, Principles of Satellite Communications, 11. 

U.S. Army Signal Center of Excellence, “The Army Satellite Communications Architecture Book,” 

2-23. 
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radios are capable of pushing into the upper spectrum of VHP beyond SINCGARS. While 
the U.S. military can allocate specific bands within VHP through a formal request process 
to support testing and operations, amateur radio bands support quick turnaround and 
development since they are always available to those with the appropriate licenses. 
Therefore, in terms of this specific experiment, amateur radio license constraints limit the 
available frequencies. VHP transmissions for SAVIOR-Cube are thus limited to the 
primary VHP frequencies allowed with an amateur radio license in the United States: 50- 
54 MHz and 144-148 MHz.^l A further comparative analysis of these two frequency bands 
demonstrates which of these ranges is best suited for testing. 

In evaluating the tradeoff between 50 MHz and 144 MHz, there are a number of 
key factors to consider, but ionospheric reflection is of chief importance due to its 
implications for HP and VHP communications. The ionosphere is a region of the Earth’s 
atmosphere consisting of charged particles (ions) residing approximately 50-650 km above 
the Earth’s surface.Most layers of the Earth’s atmosphere possess a neutral charge, but 
the charged nature of the ionosphere makes it unique. Energy from the sun, in the form of 
radiation, interacts with the gaseous atoms and molecules in the ionosphere, which forces 
the release of electrons. This results in positively charged gas ions and free electrons 
throughout the layer—hence, the name ionosphere.^3 xhe ionosphere is further divided 
into sublayers, each with its own properties of charge, density, and temperature. These 
sublayers change with solar and terrestrial weather patterns as well as the time of day.^"^ 
Regardless of any fluctuations, the charged nature of the ionosphere makes it unique 
amongst the layers of the atmosphere. Eor example, ionosphere’s charge, coupled with the 
length of HE and VHE waves, allow the radio waves to reflect off the ionosphere and travel 
great distances.This is the principle ham radios and other HE radios use to send radio 

“US Amateur Radio Frequency Allocations,” The National Association for Amateur Radio, 
accessed 03 December 2017, http://www.arrl.org/frequency-allocations. 

Ian Poole, “Radio Waves and the Ionosphere,” QST (November 1999): 1, accessed December 14, 
2017, https://www.arrl.Org/files/file/Technology/pdf/l 19962.pdf. 

Poole, 1. 

74 Poole, 2. 

75 Poole, 1. 
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transmissions to the other side of the world. For VHF, there are conflicting theories 
regarding the upper limit of VHF transmissions that reflect off the ionosphere, and the 
limits are also subject to the varying nature of the ionosphere’s layers. Regardless, lower 
frequencies have longer wavelengths and thus a higher the chance of reflection. 

While ionospheric reflection will be of utmost importance when trying to reach a 
nanosatellite in LEO, a number of key factors merit consideration for this initial test. For 
both a HAB flight and a satellite in orbit, a thorough frequency trade space analysis requires 
a breakdown of antenna size, antenna availability, and SINCGARS compatibility because 
they play an important role in the payload design; Table 7 further breaks this comparison 
down. Frequency considerations greatly affect antenna size and availability while 
SINCGARS compatibility influences the range of applications for SAVIOR-Cube. Rather 
than attempting to weight criteria—fraught with challenges associated with any ordinal 
grading system—the trade space comparison simply outlines the relative advantages and 
disadvantages of each and determines if one has a clear categorical advantage. The 
frequency with the advantage is awarded one point for that category with the number of 
points for each summed at the bottom of Table 7. Accordingly, the frequency with the 
highest number of total points has the overall advantage. 


Table 7. Frequency Trade Space Comparison 



50-54 MHz 

144-148 MHz 

Implications 

Ionospheric 

Reflection 

Long wavelengths 
make lower frequencies 
more susceptible to 
reflection. 

Higher Frequencies are 
less affected by 
ionospheric reflection. 

Higher frequencies are 
less susceptible to 
reflection and 144 MHz 
is thus better. 

Antenna Size 

Larger wavelengths 
require larger antennas 

Shorter wavelengths 
require smaller 
antennas. 

144 MHz antennas have 
less mass, are shorter, 
and are more portable. 

Antenna 

Availability 

Due to the popularity 
of amateur radio use. 

Antennas are widely 
available due to amateur 

Additional antennas 
make designing the 

antennas in the 50 MHz 
range are widely 
available. 

radio allocations and 
automatic packet 
reporting system radios. 

experiment easier and 
drives costs down; 144 
MHz is better. 

SINCGARS 

50 MHz is within the 

144 MHz is not within 

50 MHz is better due to 

Compatibility 

SINCGARS range. 

the SINCGARS range. 

its compatibility. 

Results 

1 Point 

3 Points 

144 MHz is best in three 
of the four categories. 
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Fortunately, the results of the trade space comparison are clear: 144 MHz is better 
suited for testing a VHF nanosatellite relay onboard a HAB. The smaller wavelengths 
associated with 144 MHz positively influence ionospheric reflection, antenna size, and 
antenna availability. While the lack of SINCGARS compatibility for 144 MHz is negative, 
the trade space analysis in the following section reveals that most man-portable radios in 
use by U.S. military forces across the globe operate in the full range of VHF 
communications; SINCGARS bands do not limit this test. Thus, in terms of the VHF bands 
available for testing with an amateur radio license, 144 MHz is best. Regardless of the 
frequency used for the initial concept test, the experimental conditions are adjustable to 
support a range of frequencies within VHF for subsequent SAVIOR-Cube tests. 

C. PAGING SAVIOR-CUBE 

Beyond the frequency spectrum, the next step to define in a SAVIOR-Cube test is 
which radio to use for communicating with the SDR. Traditionally, frequencies within the 
VHF range support LOS communication for mobile ground forces, so this experiment thus 
utilizes man-portable VHF capable radios currently employed by U.S. forces. Furthermore, 
the decentralized nature of most special operations makes U.S. SOF the most likely 
candidate to benefit from SAVIOR-Cube. The most commonly used VHF radios by U.S. 
SOF today are the Harris PRC117 and the Harris PRC152. Both are similar in capacity— 
capable of a range of voice and data transmission from VHF to UHF—with the biggest 
differences being size and power. The PRC 117 is simply a larger version of the PRC 152, 
which means more mass but also more transmit power. Some slight differences exist 
between the two radios’ data rates and advanced capabilities, but for simple VHF voice 
transmissions they are virtually the same in terms of capability. Figure 8 is a side-by-side 
comparison of the two radios. 
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Figure 8. Harris’ PRC 117 (left) and PRC 152 (right)^^ 


Analyzing the two similarly matched radios by comparing mass, transmit power, 
frequency range, and receive threshold helps in judging which radio meets the needs of this 
experiment. Since the payload is designed to support man-portable radios, less mass 
equates to greater portability. Transmit power, frequency range, and receive threshold all 
affect the strength of the communication link. Table 8 lays out the relative advantages and 
disadvantages of each radio in the same manner as Table 7. 


Table 8. Man-Portable Radio Trade Space Comparison 



PRC11777 

PRC15278 

Implications 

Mass 

5.44 kg (with battery) 

1.20 kg (with 
battery) 

The PRC 152 is lighter and more 
mobile; it has the advantage. 




The PRC 117 has a larger transmit 

Transmit 

Power 

10.0 W 

5.00 W 

power, but the budgets in Chapter II 
demonstrate 5 W will reach LEO; 
neither has an advantage. 




While the PRC 117 has a larger range. 

Frequency 

Range 

30-2000 MHz 

30-870 MHz 

anything beyond VHP is moot for this 
experiment; the two are equal in this 
category. 

Receive 

Threshold 

-118 dBm 

-116 dBm 

The extra margin of 2 dBm provided 
by the PRC 117 may prove the 
difference in closing a downlink; the 
PRC 117 is best. 

Results 

1 Points 

1 Point 

The two radios are tied. 


76 Source; Harris Corporation, “Harris III AN/PRC-117G(V)1(C)”; “Harris Falcon III AN/PRC- 
152A,” Harris Corporation, 2017, https://www.harris.com/sites/default/files/downloads/solutions/harris- 
falcon-iii-an-prc-152a-wideband-networking-handheld-radio.pdf. 

77 Harris Corporation, “Harris IH AN/PRC-117G(V)1(C).” 

78 Harris Corporation, “Harris Falcon III AN/PRC-152A.” 
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Unlike the frequency comparison, the results of comparing the man-portable radios 
are not precisely clear as each has obvious advantages in certain categories. However, due 
to the portability of the PRC152, it serves as the primary form of communication for the 
HAB test. Yet the PRC117 still aids as a secondary method for payload communication 
due to its higher transmit power and larger receive threshold. In other words, it receives 
weaker signals than the PRC152. While later testing may only require smaller radios with 
less power, the initial proof of concept requires ground-based communication redundancy 
to ensure a successful test. Accordingly, the PRC 152 is the primary man-portable radio for 
communicating with SAVIOR-Cube, with augmentation by the PRC 117 as necessary. 

D. THE HEART OF SAVIOR-CUBE 

With a clear understanding of the frequency spectrum and ground-based radios, the 
next and most important parameter in the trade space analysis is determining which SDR 
best functions as a VHP relay. While the SDR field is burgeoning with experimentation 
and innovation, it primarily focuses on commercial and amateur applications. Fortunately, 
Ettus Corporation (a branch of National Instruments) makes a number of VHF-capable 
SDRs that could support military requirements. The two most suited for testing in a HAB 
are Ettus Corporation’s B205-Mini and the E310. Both function in VHE ranges, are 
relatively light weight, and do not require massive amounts of power to function. Figure 9 
provides a side-by-side comparison of both SDRs. 



Figure 9. Ettus Corporation’s B205-Mini (left) and E310 (right)^^ 


Source: “USRP B200mini Series,” Ettus Research, 2017, https://www.ettus.com/content/files/ 
USRP_B200mini_Data_Sheet.pdf; “USRP E310,” Ettus Research, 2017, https://www.ettus.com/content/ 
files/ USRP_E310_Datasheet.pdf 
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As with frequency and man-portable radios, a trade space analysis helps outline the 
relative advantages and disadvantages of each. Specifically for these two radios, an 
analysis of mass, power consumption, signal strength, temperature survivability, and the 
SDR form factor assists in comparing these similar radios. Mass affects the overall weight 
of the HAB; power consumption influences the HAB power requirements and estimated 
operating time. Temperature survivability obviously influences the ability of SAVIOR- 
Cube to function in a range of environments, and the dimensions of each form factor affect 
the HAB bus mechanical interface and volume. Lastly, the output signal strength directly 
influences the margin of the downlink. Table 9 makes this comparison in the same manner 
as Tables 7 and 8. 


Table 9. Software-Defined Radio Trade Space Comparison 



B205-Mini80 

E31081 

Implications 

Mass 

90.0 g (with 
enclosure) 

375 g 

Less mass in a HAB is an advantage; 
the B205-Mini is better. 

Power 

Consumption 

5.00 V (USB 
powered) 

5.00-15.0 V 

The lower power requirements and 
the USB powered option of the 

B205-Mini are advantageous. 

Signal 

Strength 

10 dBm 

10 dBm 

Neither has an advantage. 

Temperature 

Survivability 

-40.0 to 75.0°C (with 
enclosure) 

0 to 45.0°C 

With the enclosure, the B205-Mini 
has a larger temperature range, 
giving it better survivability. 

Dimensions 

83.3 X 50.8 X 8.4 mm 

133 X 68 X 26.4 mm 

The smaller size of the B205-Mini is 
an advantage. 

Results 

4 Points 

0 Points 

The B205-Mini has the advantage in 
four of the five categories. 


The results of Table 9 demonstrate that Ettus Corporation’s B205-Mini is best 
suited to test the SAVIOR-Cube concept in either a HAB or as a prototype in LEO. Its 
smaller mass, low power requirements, and small dimensions are ideal for this testbed. 
Additionally, its increased temperature survivability with the enclosure makes it the mostly 


Ettus Research, “USRP B200-Mini Series.” 
81 Ettus Research, “USRP E310.” 
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likely candidate for surviving a test flight. Thus, the B205-Mini meets the key requirements 
for building the payload; it will serve as the heart of SAVIOR-Cube. 

E. A RASPBERRY PI IN THE SKY 

After the SDR, a payload computer is the next component of SAVIOR-Cube’s 
design. While the B205-Mini is the appropriate SDR for the payload, it still requires a 
computer for sending and receiving commands and processing GNU Radio. Fortunately, 
the requirements are relatively low, and a single board computer—a computer built on a 
single circuit board—^provides enough power and processing speed. The most widely 
available single board computers are Raspberry Pi computers; these small single board 
computers support a myriad of tasks from video gaming to file storage. Specifically for 
SAVIOR-Cube, the Raspberry Pi 2 and the Raspberry Pi 3 are appropriate because the less 
sophisticated models of the Raspberry Pi do not have the processing power to drive an 
SDR. Therefore, they cannot support the demands of this payload. Figure 10 depicts a 
standard Raspberry Pi computer. 



Figure 10. Raspberry Pi Single-Board Computer^^ 

For this next comparison, the familiar categories of dimensions (form factor) and 
mass arise, in addition to processing speed and random-access memory (RAM). Form 
factor and mass are important for the obvious reasons of HAB weight and size. For a 
computer, processing power is key. Faster processing speed equates to more horsepower 
driving the SDR; it lowers the chance of the SDR and the computer crashing. Lastly, 

Source: “Raspberry Pi Hardware Guide,” Raspberry Pi Learning Resources, accessed January 8, 
2018, https://www.raspberrypi.org/learning/hardware-guide/. 
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random access memory (RAM) assists in running multiple complex programs and 
operations simultaneously. Table 10 makes this comparison for the two computers in the 
same manner as the previous tables. 


Table 10. Raspberry Pi 3 Trade Space Comparison 



Raspberry Pi 2^3 

Raspberry Pi 3^"^ 

Implications 

Dimensions 

85.6 X 56.5 X 17 mm 

85.6 X 56.5 X 17 mm 

Neither has the advantage. 

Mass 

45.0 g 

45.0 g 

Neither has the advantage. 

Processing 

Speed 

0.9 GHz 

1.2 GHz 

The greater processing speed of the 
Raspberry Pi 3 increases payload 
reliability; it is better. 

RAM 

1 GB at 450 MHz 

1 GB at 900 MHz 

The higher RAM speed of the 
Raspberry Pi 3 supports complex 
operations; it has the advantage. 

Results 

0 Points 

2 Points 

The Raspberry Pi 3 has the advantage 
in the two remaining categories. 


As Table 10 demonstrates, the Raspberry Pi 3 is best suited to serve as the payload 
computer. Its faster processing speed provides a more robust payload with a lower 
probability of computer and SDR crashes. While the RAM size of the Raspberry Pi 2 and 
Pi 3 are the same, the faster RAM speed of the Pi 3 provides an advantage for functioning 
speeds. With this single board computer comparison complete, an important piece of the 
payload—a Raspberry Pi 3—adds to the design of SAVIOR-Cube. 

F. RECEIVING AND TRANSMITTING 

Next, antennas are an important aspect to the design, as the payload will require an 
antenna to receive and transmit signals. However, antenna theory is an often debated and 
complex topic. Providing the most efficient method of communication requires a specific 
antenna length as it relates to a frequency’s wavelength. For example, 144 MHz signals 


Andrew Williams, “Raspberry Pi 3 vs Pi 2: What’s the Difference,” Trusted Reviews, February 29, 
2016, accessed January 8, 2018, http;//www.trustedreviews.com/opinion/raspberry-pi-3-vs-pi-2-2936374. 

Williams. 
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have a wavelength of approximately 2 This principle is based on a conversion between 
wavelength and frequency, which Equation 3 demonstrates.^^ 

A = c/f (Equation 3) 

Where lambda (A) represents the wavelength in meters, c is the velocity of light in 
meters per second, and / represents the frequency in gigahertz. Using the principles behind 
this equation antennas are constructed to correspond to frequency’s wavelength. Generally, 
this results in antenna length that roughly corresponds to approximately Vi or *4 of that 
signal’s wavelength in order to maximize antenna gain and minimize loss.^^ Additionally, 
antenna material affects gain as do a number of other factors such as antenna radiation 
patterns.As a result, picking the correct antenna to support a HAB test is key. 

Eor SAVIOR-Cube, the two most widely available and cost-effective antennas that 
support transmissions in the 144 MHz range are the Byonics Company’s V6 Dipole 
Antenna and the V2 Whip Antenna. Both are tuned for 144 MHz and have the appropriate 
gain, mass, and flexibility to support SAVIOR-Cube’s intended purpose. Eigure 11 is a 
side-by-side comparison of the two antennas. 



Eigure 11. Byonics V2 Whip Antenna (left) and V6 Dipole Antenna (right)^^ 


The National Association for Amateur Radio, “US Amateur Radio Frequency Allocations.” 
Gordon, Principles of Satellite Communications, 98. 

“Antenna Basic Concepts,” Pulse Electronics, 2018, accessed 04 February 2018, 
https://www.pulseelectronics.com/antenna_basic_concepts/. 

Pulse Electronics. 

Source: “MicroTrak VHF Antennas,” Byonics LLC, accessed February 4, 2018, 
http://www.byonics.com/antennas. 
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Specifically for making this trade space comparison, the factors to consider are 
antenna length, gain, mass, and structural flexibility. Length is important because the actual 
length of the antenna affects the shape of the HAB design. In terms of a HAB, for example, 
a longer antenna may impede the deployment of parachutes. Gain is important for ensuring 
the communications link closes. Mass will affect the overall HAB mass, and less mass is 
therefore advantageous. The antenna material’s structural flexibility must allow the 
antenna to be manipulated during transit, to be placed on the most advantageous location 
of the HAB, and to survive a parachute deployment. Table 11 makes the trade space 
comparison for the two antennas in the same manner as the previous tables. 


Table 11. Antenna Trade Space Comparison 



V2 Whip Antenna^O 

V6 Dipole Antenna^l 

Implications 

Antenna 

Length 

37.0 cm 

94.0 cm 

The shorter length of the V2 
antenna is best. 




While the V6 is touted to have 
better gain than the alternative 

Gain 

2.15 dB 

2.15 dB 

Byonics’ antennas, the company 
lists 2.15 dB as the gain for each; 
neither has a clear advantage. 

Mass 

34.0 g 

11.3g 

The lighter mass of the V6 antenna 
makes its best for a HAB. 

Flexibility 

A sturdy whip with a 
rubber coating. 

Flexible spring steel 
music wire. 

The described flexibility of the V6 
gives it a better chance of surviving 
a HAB flight; it has the advantage. 

Results 

1 Points 

2 Points 

The V6 Dipole Antenna has the 
advantage in two the categories. 


To support a HAB test, the V6 dipole antenna is best. While its length is slightly 
cumbersome, the lower mass assists in minimizing launch budgets. Additionally, the 
antenna’s flexibility facilitates payload transportation and gives it the best chance of 
surviving a test flight. This antenna serves as both SAVIOR-Cube’s receive and transmit 
antenna—supporting uplink and downlink communications. While later tests will require 


Byonics LLC. 
Byonics LLC. 
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custom-designed antennas that survive launch and orbit, this antenna suffices for initial 
HAB experimentation. 

G. AMPLIFYING THE SIGNAL 

In order to increase the margin of the communication downlink and ensure a 
successful test, an amplifier is the final piece of SAVIOR-Cube’s design. It strengthens the 
signal the B205-Mini SDR transmits. While Chapter IV further discusses the 
communication link budgets specific to the HAB flight, SAVIOR-Cube’s communication 
link margin requires a small amplifier in the 144 MHz range. Specifically, SAVIOR-Cube 
requires an amplifier that increases the transmit signal above the B205-Mini’s advertised 
signal strength of 10 dBm, easily fits in a HAB, and requires approximately 5 volts or less 
of power. Few commercially available amplifiers fit these criteria because most require 12 
volts or more of power. However, the two that seem best suited for SAVIOR-Cube testing 
are Mini-Circuits’ ZX60-V82-I- Wideband Amplifier and ZX60-63-I- Wideband Amplifier. 
While voice transmissions are generally narrowband, these amplifiers are considered 
wideband because they support a wide range of frequencies. However, they also support 
narrowband voice transmissions. Both also meet the strict power requirements of a HAB, 
are small in terms of form factor, can survive a wide-range of temperatures, and increase 
the signal beyond that of the B205-Mini. Figure 12 depicts a Mini-Circuits amplifier. 



Figure 12. Mini-Circuits Wideband Amplifier^^ 


In terms of these two amplifiers, there are a number of factors to consider. First, the 
dimensions of the amplifier are key because a smaller amplifier will fit easier into a HAB. 

Source: “ZX60-V63+ Wideband Amplifier,” Mini-Circuits, 2017, accessed February 4, 2018, 
https://www.minicircuits.com/pdfs/ZX60-V63+.pdf 
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Next, operating temperature is important because it affects the amplifier’s survivability for 
a HAB flight. Output power at approximately 144 MHz is crucial for closing the 
communication downlink. Lastly, voltage and power consumption determine how well 
each function with the limited power supply onboard a HAB. Table 12 makes this 
comparison for the two amplifiers in the same manner as the previous tables. 


Table 12. Amplifier Trade Space Comparison 



ZX60-V82-I-93 

ZX60-63-I-94 

Implications 

Dimensions 

1.91 X 1.91 cm 

1.91 X 1.91 cm 

Neither has the advantage. 

Temperature 

Survivability 

-40.0 to 85.0°C 

-40.0 to 85.0°C 

Neither has the advantage. 

Power 

Output 

19 dBm 

18.4 dBm 

The ZX60-V82-I- signal output is larger by 
.6 dBm; it is better. 

Voltage 

5.50 V 

5.70 V 

The ZX60-V82-I- requires less voltage and 
thus has the advantage. 

Power 

Consumption 

0.84 W 

0.50 W 

The ZX60-63-I- has a lower power 
consumption and is thus better. 

Results 

2 Points 

1 Points 

The ZX60-V82-I- amplifier has the 
advantage in two of the categories. 


Based on the results shown in Table 12, the ZX60-V82+ Wideband Amplifier is 
marginally better suited for testing SAVIOR-Cube during a HAB flight. The slightly larger 
dBm margin it provides assists with closing the downlink and the lower voltage helps to 
minimize power requirements. This amplifier is crucial for boosting SAVIOR-Cube 
transmissions at a relatively low power cost. More importantly, it is the final piece of 
SAVIOR-Cube’s initial EDU. 

H. CHAPTER CONCLUSION 

From the trade space analyses of frequencies, man-portable radios, SDRs, 
computers antennas, and amplifiers, the best parameters and hardware for initial SAVIOR- 
Cube testing are clear: a PRC152 (augmented by a PRC117 if necessary) broadcasting in 

“ZX60-V82+ Wideband Amplifier,” Mini-Circuits, 2017, accessed February 4, 2018, 
https://www.minicircuits.com/pdfs/ZX60-V82+.pdf. 

94 Mini-Circuits, “ZX60-V63+.” 
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the 144 MHz range to a B205-Mini SDR with a Raspberry Pi 3, dipole antenna, and 
wideband amplifier. 144 to 148 MHz is better suited than 50 MHz due to its advantages in 
ionospheric reflection, antenna size, and antenna availability. The PRC152 is easily 
portable, and it has enough power to reach a HAB in flight. Ettus Corporation’s B205-Mini 
is better suited than the E310 due to its smaller size and weight, as well as better 
temperature survivability. A Raspberry Pi 3’s faster processing speeds and RAM support 
the payload better than a Raspberry Pi 2. Einally, a V6 dipole antenna and the ZX60-V82-I- 
amplifier increase the chances of the downlink closing. Eigure 13 depicts the initial EDU 
for SAVIOR-Cube. 


Raspberry 
Pi 3 


r 


I 


B205-Mini 

SDR 


Incoming 

Signal 



Outgoing 

Signal 


Eigure 13. Initial SAVIOR-Cube EDU 


These conditions and hardware are the most conducive for testing in a HAB and 
the most likely conduits for success. This trade space analysis lays the groundwork for 
SAVIOR-Cube by outlining its appropriate design for a HAB. While this chapter focuses 
on the trade space analysis for building an EDU that supports testing the payload in a HAB, 
the next chapter discusses the parameters and results from environmental and operational 
testing in the lab, outdoors, and onboard a HAB. 
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IV. TESTING SAVIOR-CUBE 


As the previous chapters of this thesis demonstrate, the U.S. military is highly 
reliant upon space-based technology, and this is particularly the case with satellite 
communication (SATCOM). Consequently, alternative forms of SATCOM that leverage 
existing communication capabilities such as very high frequency (VHP) line of sight (LOS) 
transmissions, coupled with nanosatellite technology, will build resiliency into the U.S. 
infrastructure, much like the Software Assisted VHP Information Overhead Relay-Cube 
Satellite (SAVIOR-Cube). Portunately, with the initial engineering design unit (EDU) from 
the trade space analysis in the previous chapter complete, the results of numerous iterations 
of SAVIOR-Cube testing now merit discussion and analysis. Initial testing occurred on the 
laboratory bench, improving the payload design, monitoring power, and measuring signal 
strength. Next, SAVIOR-Cube underwent outdoor operational testing to help finalize the 
design and identify any hardware or software shortfalls, after which the final EDU was 
constructed. The software coding that commands SAVIOR-Cube was also finalized, 
completing the design. With a final EDU in hand, environmental testing ensured that 
SAVIOR-Cube would survive a high-altitude balloon (HAB) flight. Einally, the payload 
flew in a HAB as a proof concept test for an overhead VHE relay. The results of these 
numerous iterations of testing, in the lab and in the field, show that not only is a software- 
defined radio (SDR) VHE relay possible, but it is a viable low-cost, near-term solution for 
building resilient and redundant pathways into the U.S. military SATCOM infrastructure. 

A. DIVING INTO GNU RADIO 

Prior to a discussion of the tests conducted, a brief description of the programming 
behind SAVIOR-Cube’s software design provides clarity. As Chapter I briefly discusses, 
the payload utilizes GNU Radio—an open-source program for programing SDRs. In this 
instance, the payload is programmed to function as a bent-pipe relay: receiving an analog 
signal, modulating the signal into a digital form, filtering as necessary, modulating the 
signal back to an analog form, and broadcasting it on a different frequency. Beyond the 
hardware required to perform these functions, the payload software must adequately 
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support such operations. The flowchart in Figure 14 graphically depicts the initial GNU 
Radio receive flow graph prior to extensive testing. 
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Figure 14. Initial GNU Radio Receive Flow Graph 


The initial block on the far left of the flow graph in Figure 14 is the receive block, 
entitled UHD: USRP Source. It defines the frequency, gain, and media access control 
(MAC) address of the device receiving the signal; it tells the payload how to listen for a 
signal. In this case, the Raspberry Pi 3 uses the information in the receive block to 
communicate with the B205-Mini SDR. The next block. Low Pass Filter, narrows the 
bandwidth of the received signal to a specified range centered on the desired receive 
frequency. After that, the subsequent box in the flow graph is Power Squelch, which 
essentially mutes frequencies below a certain threshold (a minimum number of dBm), i.e., 
weak signal sources. Lastly, the File Sink block writes the received transmissions to a 
binary file on the Raspberry Pi 3 for rebroadcasting when recalled. 

Upon receipt of the transmissions, the payload is also programmed to transmit a 
recently recorded transmission. Figure 15 contains the initial transmit flow graph. 
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Figure 15. Initial GNU Radio Transmit Flow Graph 

The far-left block in Figure 15 is the File Source block. It simply tells the SDR to 
open a specific file, in this case the previously recorded transmission. That block leads into 
the USRP Sink, which is a transmission block that acts similarly to the USRP Source, but 
simply transmits rather than receives. It specifies the frequency, transmit gain, device 
address, and a few other parameters. There are also numerous variable and graphical user 
interface (GUI) blocks around the periphery of the flowchart. These are simply used to 
visualize the process and modify certain values quickly, such as receive and transmit 
frequencies, gain, power squelch, and other customizable features for testing. This simple 
flow graph depicts how the payload receives a transmission on a specific frequency and 
subsequently filters, saves, and replays it on a different frequency—serving as an initial 
software design for SAVIOR-Cube. 

B. LABORATORY TESTING 

With the initial hardware and software designs complete, SAVIOR-Cube endured 
extensive bench testing. Iterative bench testing began with simple tests to ensure the 
payload functioned and the transmitted signal remained strong. In the lab, a spectrum 
analyzer tuned to the same frequency range as the payload’s receive and transmit 
frequencies (144-148 MHz) allowed signal pattern and strength analysis. SAVIOR-Cube 
was assembled as designed with the SDR, Raspberry Pi 3, amplifier, and antennas. 
Additionally, the payload, via the Raspberry Pi 3, had a computer monitor, a keyboard, and 
a mouse to allow for easy manipulation while testing, as depicted in Figure 16. The test 
consisted of setting up the payload and adjusting the software design while the payload 
functioned. This supported fine-tuning of the various payload parameters such as the 
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receive and transmit gain and power squelch. In addition, bench testing allowed for 
iterative testing of the software design for the payload, eventually leading to the most 
advantageous software design for SAVIOR-Cube. 
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Figure 16. Bench Testing Set-up 


Initially, the testing focused on establishing the appropriate parameters for receive 
and transmit gain. Specifically, it concentrated on how to appropriately set the gain levels 
for each to ensure both signals were audible. The challenge with voice transmissions is that 
while a spectrum analyzer measures signal strength in terms of dBm, a determination on 
signal quality depends upon someone listening to it. In other words, a person must 
determine the signal quality based upon what they hear. Unfortunately, this process is less 
than precise. However, if the same person conducts the series of tests, a general baseline is 
achieved. A baseline helps to judge the change in signal quality during bench tests in the 
lab. This process proved successful for testing SAVIOR-Cube in the lab. 

For testing, the payload was initially assembled with all components, connected to 
the appropriate peripherals such as a monitor and a keyboard, and powered on. Next, a 
PRC 152 radio was turned on and tuned to the appropriate frequencies to support the test 
within the 144-148 MHz range. For the lab tests, the receive frequency on the SDR was 
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set to 145.5 MHz, and the transmit frequency was set to 147.0 MHz. With these parameters, 
both the receive and transmit gain were set to 0.00 dB as a baseline. The PRC152 then 
transmitted a simple voice transmission on 145.5 MHz, which the SDR received and 
retransmitted on 147.0 MHz. After iteratively adjusting the receive gain, the best range was 
determined to be between 10.0 and 20.0 dB. Below 10.0 dB, the received signal was too 
weak; above 20.0 dB, the received signal was over-amplified—it was inaudible. In terms 
of transmit gain, the required levels were much higher. Below 30.0 dB, the signal was too 
weak for the PRC152 to receive. The receive gain was increased, and eventually 70.0 dB 
was found to be best for audible voice transmissions. Below 60.0 dB, the signal was weak; 
above 75.0 dB the signal was over-amplified. Based upon this test, the optimal receive gain 
for lab testing is generally 15.0 dB and the optimal transmit gain is generally 70.0 dB. 

With the receive and transmit gain set, the next parameters to test in the lab were 
bandwidth filters and power squelch. For the B205-Mini, the minimum receive bandwidth 
is 200 kHz, which is too large for simple voice transmissions.A bandwidth that wide 
causes the SDR to retransmit much too sizable a signal. Generally, 5.00 kHz of bandwidth 
is sufficient for simple voice transmissions. A larger bandwidth includes too much noise, 
and a smaller bandwidth limits the quality of the voice transmissions. Due to these reasons, 
a low pass filter block within GNU Radio limited the received transmission to 5.00 kHz of 
bandwidth centered on the specified receive frequency with 2.50 kHz of bandwidth above 
and below that center frequency. 

Beyond bandwidth filtering, power squelch also filters the signal appropriately. 
Specifically, it mutes received frequencies below a certain threshold. If the power threshold 
is too low, the payload will retransmit too much noise; too high, and it will not receive 
intended transmissions. With SAVIOR-Cube’s purpose in mind, the lower the receive 
threshold, the better. In other words, the payload is designed to receive weak transmissions 
over a distance, and thus a low margin is best. Generally, if the margin is too low it picks 
up unintended transmissions. After a number of tests, a range between -60.0 to -70.0 dBm 
worked best. Below -60.0 dBm, the payload failed to pick up intended transmission; above 
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-70.0 dBm and it rebroadcasted too much noise. Thus, the default power squelch for 
SAVIOR-Cube is -65.0 dBm. With a bandwidth filter of 5.00 kHz and a power squelch of 
-65.0 dBm, the appropriate filters support payload functionality. 

After the filters and software were set, the payload required some basic power 
testing. Specifically, the testing included baseline power for the assembled payload, the 
maximum power limit, and the minimum power requirement. For baseline power, the 
payload was attached to a lab bench power supply via a power harness designed 
specifically for SAVIOR-Cube. The power supply provided 5.00 V since both the SDR 
and Raspberry Pi 3 require 5.00 V to function.96 This lab set-up allowed for easy 
monitoring of the payload current draw, measured in amperes (A). With this configuration, 
the baseline power requirements for SAVIOR-Cube—the voltage and current necessary to 
power the payload, but not fully operate—is 5.00 V and 800 mA, which equates to 4.00 
W. This value is derived from Equation 4, where power (P) in watts is equal to current (I) 
in amperes multiplied by voltage (V). 

P = IV (Equation 4) 

However, while receiving and transmitting signals, the payload power requirements 
fluctuated from the baseline. During a HAB flight specifically, peak power matters because 
it demonstrates the maximum power requirements of a system while operating. A test 
designed to monitor peak power thus provided clarity for understanding the payload’s 
power requirements. For the test, the payload functioned while the voltage remained at 
5.00 V, but the current fluctuated due to payload operations. Peak payload operations 
consisted of receiving transmissions, recording transmissions, and sending transmissions. 
During these modes, the current peaked at 1.50 A, resulting in a total of 7.50 W at peak 
operating modes. The last power test concerned minimum operating voltage. Minimum 
power requirements are important for real-time data and post-flight analysis because in the 
event that the voltage supplied to the payload drops below the normal value of 5.00 V, it is 
essential to know at what voltage the payload ceases to function. For this experiment, the 
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set-up remained the same with the payload operating and the bench power supply set to 
5.00 V. The voltage supplied to SAVIOR-Cube via the bench supply was slowly lowered 
in increments of 0.50 V. Interestingly, the payload functioned within the expected 
parameters—adequately receiving and transmitting signals—until the voltage supplied to 
the payload dropped below 4.00 V. In other words, as soon as the voltage fell below 4.00 
V, the payload failed and no longer functioned. Table 13 break down these values as they 
relate to payload power. 


Table 13. Payload Electrical Power System Requirements 


Mode 

Voltage 

Current 

Power 

Baseline 

5.00 V 

0.80 A 

4.00 W 

Peak Power 

5.00 V 

1.50 A 

7.50 W 

Minimum Required 

4.00 V 

1.00 A 

3.20 W 


As Table 13 shows, the payload operated in a voltage range from 4.00-5.00 V, and 
the current ranged from 800 mA to 1.50 A for a total wattage range from 3.20-7.50 W. If 
power drops during a flight, the payload will still function until the voltage falls below 4.00 
V—a promising power range. With these series of tests in the lab, SAVIOR-Cube finished 
its rounds on the lab bench. It was ready to graduate to the field and begin operational 
testing. 


C. OPERATIONAL TESTING 

Outside the lab, the SAVIOR-Cube payload was also tested across the Naval 
Postgraduate School (NPS) campus. The intent was to identify weaknesses in the payload 
design that escaped detection in the lab. First, a series of tests identified distance-related 
constraints and how they affect payload functionality. For the first test, PRC 152 radios 
were separated from the payload by incremental distances ranging from 10 m to 250 m 
while the payload operated, sending and receiving transmissions. Figure 17 depicts on- 
campus operational testing, with the SAVIOR-Cube payload connected to a laptop for easy 
manipulation while testing, and two PRC152 radios nearby to send and receive 
transmissions via the payload. 
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Payload 

Figure 17. On-Campus Operational Testing 

Though the payload functioned outside the lab, the on-campus test helped identify 
that the SDR was struggling to receive weaker signals, which would be a problem during 
flight. Specifically, when the PRC 152s were more than 50 m from SAVIOR-Cube, the 
received transmissions were too weak for the payload to receive clearly. Additionally, the 
transmitted signal quality and strength were directionally proportional to the received 
signal quality and strength. In other words, if the received signal was weak in terms of 
dBm, then the transmitted signal was also weak. Based on this information, the payload 
needed a low noise amplifier to increase SAVIOR-Cube’s ability to receive weak signals. 
Furthermore, it required a change to the software design within GNU Radio; it needed an 
additional block to ensure the transmitted signal was always near the same level regardless 
of the received signal strength. 

In order to deal with the first problem, a low noise amplifier was installed to 
increase the received signal strength. Mini-Circuits Corporation’s ZX60-P103LN-I- low 
noise amplifier is ideally suited for solving this problem because it increases a received 
signal by 20.0 dB. Furthermore, its small form factor and mass, similar to the wideband 
amplifier installed for the transmit signal, ensured that it would fit within the allowable 
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payload volume in the HAB bus, and it met the supplied voltage requirement of 5.00 V. 
Figure 18 depicts a rudimentary diagram of the final SAVIOR-Cube hardware design. 
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Figure 18. Final SAVIOR-Cube Design 


For the second issue, equalizing the transmit signal strength, an Automatic Gain 
Control block installed in the GNU Radio flow diagram solved the problem. It is a simple 
block that increases all transmitted signals to the same level. In this case, it is programmed 
to increase all signals to approximately 0.00 dB. Regardless of the weakness of the signal 
received, the Automatic Gain Control block raises the signal strength to 0.00 dB prior to 
the reaching the SDR. However, with the low noise amplifier, the receive gain also required 
adjusting to ensure the signal was not over-amplified. Thus, the receive gain was adjusted 
to -10.0 dB, ensuring the signal was not too intense. With these changes, the on-campus 
test was repeated. Fortunately, the changes proved successful, and SAVIOR-Cube 
functioned well across the NFS campus with a final distance of up to 500 m. 

With the success of the on-campus operational test, the payload was then tested 
over a longer distance, approximately 3.5 km. The payload was placed on the roof of 
Spanagel Hall on the NFS campus. A FRC152 radio, approximately 3.5 km away, was at 
Jack’s Feak County Fark with a clear LOS of the NFS campus. Despite the distance 
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between the SDR and the PRC152, the payload functioned as designed. Figure 19 depicts 
a map of this test, demonstrating the distance between the payload and the PRC152 radio. 



Figure 19. SAVIOR-Cube LOS Field Test 


To simulate a greater distance between the SDR and the radio, 30.0 dB of manual 
attenuation were added to weaken the signal via physical attenuators. Due to free-space 
path loss and the added attenuation, that was a signal of approximately -96.6 dBm, 
equivalent to a distance of approximately 101 km (not counting receiver, transmitter, and 
miscellaneous losses or gains). Thus, the results of this specific test demonstrate that 
SAVIOR-Cube could function over a distance of 100 km away from a ground-based radio 
such as a PRC152. 

Beyond the payload tests, operational testing was also conducted to ensure the 
radios used to communicate with the HAB would effectively close the communications 
link over a distance. Given that the PRC 152 handheld radios are the primary form of 
communication with the payload, a LOS field test was performed to ensure they will 
suffice. Specifically, a PRC152 was located on the roof of Spanagel Hall on the NPS 
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campus, and a second was 19.6 km northeast of the NPS campus on a ridgeline west of 
Mount Toro, CA. A LOS communication test between the radios to test the receive margin 
of the PRC 152 demonstrated their strength, as the map in Figure 20 depicts. 



Figure 20. PRC 152 LOS Field Test 


With a combination of free-space path loss and manually added signal attenuation, 
the test demonstrated that the PRC152 could effectively receive a signal of -106 dBm, well 
below the lowest signal expected during the HAB flight. This test helped establish 
confidence in the equipment used to test SAVIOR-Cube and proved that the PRC 152s 
could communicate with a HAB overhead. With these iterative tests completed both in and 
out of the lab, the final hardware and software design for SAVIOR-Cube was complete, 
and it was ready for environmental testing. 

D. FINAL SOFTWARE AND HARDWARE DESIGN 

Prior to discussing the results of environmental testing or the HAB flight, a 
description of the final payload hardware and software design provides a final picture of 
SAVIOR-Cube’s physical and virtual configurations. In terms of hardware, the design is 
simple. The V6 dipole antenna receives the signal, which the low noise amplifier increases; 
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the signal then travels to the B205-Mini SDR where the software and Raspberry Pi 3 
modulate the signal appropriately. Next, the signal travels from the SDR to the wideband 
amplifier, increasing signal strength, and it finally radiates from the payload via a second 
V6 dipole antenna. In terms of interfaces within the payload, antenna and amplifiers 
connect via coax cables. The SDR and Raspberry Pi 3 communicate using a customized 
universal serial bus (USB) 2.0 connection. Finally, the SDR, Raspberry Pi 3, and amplifiers 
all receive their own power from a common power harness. The power harness connects 
to a common source of power, whether from a satellite bus or a lab bench. As a single unit, 
the payload fits into a custom-designed 3D-printed plastic chassis that provides a compact 
structure appropriate for a CubeSat. This design supports SAVIOR-Cube functionality. 
Figure 21 depicts this final payload design. 
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Figure 21. SAVIOR-Cube Assembly 

In terms of the final software design, the GNU Radio flow graphs provide a starting 
point for building a Python source code.97 In other words, they provide a GUI for 
manipulating the software in order to generate a Python source code to drive the payload. 
The software design also complements the desired test conditions. Specifically, the payload 
software is split into two segments that operate independently: receive and transmit. The 
receive segment consists of the USRP Source block, which sends the appropriate 

Python is a user-friendly computer programming language used widely by many open-source 
programs such as GNU Radio. 
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parameters to the SDR; followed by the Low Pass Filter set at 5.00 kHz centered on 144.8 
MHz; the Power Squelch set at -65.0 dB; the Automatic Gain Control, which raises the 
signal to 0.00 dB; and finally, two File Source blocks, which save the signal. The first block 
saves the signal to an appended binary file for post-flight analysis, supporting a complete 
review of all in-fight transmissions in the lab, while the second block sends the signal to 
an overwritten binary file for immediate retransmission. Figure 22 is this final receive flow 
graph, and Appendix A contains a breakdown of each of the final blocks in both the receive 
and transmit flow graphs. 
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Figure 22. Final GNU RADIO Receive Flow Graph 


Additionally, to help provide a baseline transmission for the payload while the 
payload is in the receive mode, SAVIOR-Cube simultaneously broadcasts a baseline .wav 
file transmission pre-recorded in the lab.98 The transmission essentially ensures there is a 
clearly recorded transmission emitting from the payload from which to judge the signal 
quality and ensure the payload functions, while also broadcasting required amateur radio 
call signs and information in accordance with U.S. regulations. It consists of the Wav File 
Source block from which the pre-recorded .wav file is opened, a Narrow Band Frequency 
Modulation (NBFM) block and a Rational Resampler block that translate the .wav file from 


A .wav file is a standard computer file type for storing audio files. 
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an audio file and into the appropriate configuration for SDR playback, and finally the 
USRP Source block, which instructs the SDR to transmit signals appropriately. Figure 23 
is the final flow graph for transmitting the .wav file. 
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Figure 23. Final GNU Radio .wav File Flow Graph 

The second flow graph, the transmit flow graph, is much simpler. The first block is 
a File Source that opens the file recorded during the receive mode, followed by a USRP 
Sink that provides the parameters to the SDR for transmitting the signal. Figure 24 depicts 
the final transmit flow graph. 
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Figure 24. Final GNU Radio Transmit Flow Graph 


Both of these flow graphs help visualize the software programming of SAVIOR- 
Cube and help generate the Python source code from GNU Radio. However, the Python 
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scripts only provide a basis for the customization required to facilitate on-demand 
parameter adjustments and a scripted receive-and-transmit cycle. The code generated by 
GNU Radio requires modification to support this specific payload and HAB flight. Custom 
Python programming merges these two flow graphs into a predictable cycle. Figure 25 
breaks down the Python cycle, and Appendix B contains the raw Python scripts. 
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Figure 25. SAVIOR-Cube Python Script Flow 


As Figure 25 depicts, the entire process first simultaneously activates the receive 
flow graph and the .wav file transmit flow graph, followed by the transmit flow graph. 
Upon activation, the payload loads the receive flow graph—or a Python source code of the 
graph—and transmits the prerecorded .wav file (approximately 10 seconds long) and 
simultaneously receives transmissions for 60 seconds. After 60 seconds, the receive mode 
ends, and the transmit mode opens after a brief but intentional delay and plays the most 
recent transmission, which takes approximately 15 seconds (based upon the length of the 
most recent transmission). This cycle lasts approximately 85-90 seconds and repeats 10 
times before the payload computer reboots, after which the cycle starts anew. The reboot 
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avoids or kills errors that might result during threading and connection within the payload, 
which occurred frequently enough during ground testing to warrant implementing this 
reboot feature to increase reliability during flight. Lastly, this Python code launches 
automatically on startup in case the payload loses power or suffers an unintentionally 
reboot. Both the final hardware and software design support easy testing and analysis for a 
HAB flight. 

E. ENVIRONMENTAL TESTING 

To ensure the finalized hardware and software designs were flight-ready, SAVIOR- 
Cube underwent environmental testing. In terms of environmental considerations during a 
HAB flight, the accelerations from winds at altitude and the jet stream as well as 
temperature fluctuations during the flight posed the biggest risks. Generally, for vibration 
constraints, winds at altitude can stress a HAB and have the potential to damage payload 
components. Throughout the flight, temperatures may fluctuate greatly from up to 35°C on 
the ground at launch to -40°C at target altitude. These extreme temperatures and dramatic 
changes over a short time can also damage payload components. As a result, these two 
potential stressors were the focus of environmental testing to ensure SAVIOR-Cube would 
survive its launch and flight. 

I. Vibration Testing 

For the vibration testing, the NPS Small Satellite Laboratory vibration table 
provided the necessary test bed. The payload was mounted in a metal 2U CubeSat structure 
(shown in Figure 26) and tested in the X, Y, and Z axes to General Environmental 
Verification Specification (GEVS) acceptance levels—a standard testing level defined by 
NASA for environmental testing.^9 Vibration testing included a baseline sine sweep to 
determine fundamental frequencies and corresponding damping, random vibration to 
simulate accelerations during high-wind conditions at altitude, and a post-test sine sweep 


99 J. Scott Milne Jr. and Daniel S. Kaufman, “General Environmental Verification Specification,” 
Goddard Spaceflight Center, January 1, 2003, accessed April 3, 2018, 
https://ntrs.nasa.gOv/archive/nasa/casi.ntrs.nasa.gov/20030106019.pdf. 
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to see if the random vibration test caused any significant structural damage. Each random 
vibration test ran for one minute at 6.80 Grms per the GEVS standard. Vibration sensors 
(accelerometers) were placed on both the SDR and Raspberry Pi 3 to individually monitor 
each component. Einally, before and after each test axis, the payload underwent a 
functional test to ensure it was still operable. The test configuration depicted in Eigure 26 
supported the individual monitoring of the key payload components and ensured survived 
the vibration tests. 



Eigure 26. Vibration Testing 


When comparing the baseline and post-sine sweeps of the Raspberry Pi 3 (Eigure 
27), the plots show that the fundamental frequencies for the Raspberry Pi 3 in the Z 
direction seemed to change slightly but less than the fundamental frequency changes in the 
X and Y directions, with the measured acceleration response on the Raspberry Pi 3 of 9.00 
Grms. The pretest and post-test signatures may have differed slightly for a number of 
reasons. Most likely, however, it was simply that the structure settled in place over the 
course of the tests. In other words, it was the first time the payload and structure were 
subjected to stress, and as they vibrated across each axis, the structure settled in place at 
the various joints and connections. Eortunately, despite any differences between the tests, 
a visual inspection of SAVIOR-Cube revealed that there were no loose screws, cracks, or 
fatigue in the payload structure. Eurthermore, the post-test payload functional test—a 
baseline test to ensure the payload functions—succeeded. The Raspberry Pi 3 survived the 
vibration testing no worse for the wear. 
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Figure 27. Raspberry Pi 3 Vibration Test Results^®® 

For the SDR, the differences between the baseline sine sweep and post-test sine 
sweep were greater than those differences observed in the Raspberry Pi 3, as Figure 28 
demonstrates. 


Ihh Source: SS4861 Payload Design Course 11: SAVIOR-Cube Final Report (Monterey, CA: Naval 
Postgraduate School Space Systems Academic Group, 2018), 24. 
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Figure 28. B205-Mini SDR Vibration Test Results^®^ 


Specifically for the SDR, there were greater anti-resonance frequencies in the post¬ 
test in the X and Y directions than the Z direction, with the measured response on the SDR 
of 9.20 Grms. Once again, a visual inspection did not reveal any damage to the structure, 
and the payload operated as intended during the functional tests. The manner in which the 

Source: SS4861 Payload Design Course II: SAVIOR-Cube Final Report, 25. 
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sensors were mounted to the case and the slight changes in the structure may have caused 
the differences between the test results. Regardless, the vibration tests did not damage the 
SDR. 

As a whole, the vibration tests built confidence in SAVIOR-Cube’s ability to 
survive a HAB flight, which the results in Figures 27 and 28 confirm. The functional tests 
and visual inspection proved that SAVIOR-Cube would still function after being subjected 
to accelerations up to 6.80 Grms, with the measured responses reaching 9.00 Grms for the 
Raspberry Pi 3 and 9.20 Grms for the SDR. These series of tests demonstrated that the 
payload is designed properly. 

2. Thermal-Vacuum (TVAC) Testing 

The second and final environmental test SAVIOR-Cube underwent was a thermal- 
vacuum (TVAC) chamber test. TVAC testing ensured the payload would survive the 
extreme temperatures and corresponding temperatures it may be subjected to during a HAB 
flight. Testing consisted of a range of hot and cold temperatures in a near-vacuum 
environment, simulating the potential high temperatures at launch up to 35.0°C, the low 
temperatures at altitude up to -40.0°C, and the pressure at altitude. The payload was thus 
placed in the NPS Small Satellite Lab TVAC chamber with sensors to monitor payload 
temperature and using the appropriate connections to allow the payload to operate during 
the test. Thermocouples monitored the SDR case and Raspberry Pi 3 case temperatures, 
and the internal temperature of the Raspberry Pi 3 was monitored with its built-in 
temperature sensor. Figure 29 depicts the payload as it was set up in the TVAC chamber. 



Figure 29. TVAC Testing 
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Within the chamber, the temperature was initially at 19.0° C—room, or ambient, 
temperature. To simulate potential conditions on the ground at launch, the temperature 
increased to 35.0°C, heat soaking the payload for thirty minutes. Next, the chamber 
temperature was lowered from 35.0°C to -40.0°C over the course of thirty minutes to 
simulate a dramatic temperature and pressure change from launch to altitude. The TVAC 
chamber maintained this minimum expected temperature for one hour to simulate the 
expected duration of the flight, subjecting SAVIOR-Cube to a cold soak. Finally, the 
chamber returned to ambient temperature and pressure to simulate landing. This profile 
simulated the various temperature ranges expected during a HAB flight. Figure 30 depicts 
the temperature profile for the TVAC test. 



Figure 30. TVAC Test Temperature Profile 


Interestingly, the temperature sensors for the various components follow a similar 
profile as one another, but the highs and lows of each vary significantly. Based on the 
manufacturing specifications, the operating temperature of the Raspberry Pi 3 should be 
maintained between -40.0 and 70.0°C, and the SDR temperature should stay between -40.0 
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and 75 . 0 °C .^®2 During the TVAC test, however, the internal temperature of the Raspberry 
Pi 3 reaehed as high as 77.0°C, and the SDR and Raspberry Pi 3 eases reaehed 
approximately 40.0°C despite the maximum ehamber temperature of 35°C. In terms of 
minimum temperatures, the internal minimum temperature reeorded for the Raspberry Pi 
3 was 17.0°C. Unfortunately, the TVAC ehamber did not sueeeed in lowering the internal 
temperature of the Raspberry Pi 3 because its internal temperature remained too high from 
prior testing to adequately lower it during the remainder of the test. However, the external 
temperature of the Raspberry Pi 3 reached -24.6°C, and the SDR case reached -6.07°C. 
While the cases and internal components themselves did not reach -40.0° C, the cold soak 
subjected the payload to the minimum and maximum environmental temperatures expected 
for the planned duration of the flight. Figure 31 graphically depicts the results of the TVAC 
testing, with the red line at the highest recorded temperatures and the blue line at the lowest 
recorded temperatures. 
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Figure 31. TVAC Testing Results 


102 “usRp B200-Mini Series,” Ettus Research; “Raspberry Pi Hardware Guide,” Raspberry Pi 
Learning Resources. 

Source; SS4861 Payload Design Course 11: SAVIOR-Cube Final Report, 28. 
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Akin to the vibration tests, the payload underwent functional testing before and 
after the TVAC test. However, it also underwent functional tests throughout the TVAC test 
to simulate the HAB flight and better understand its behavior during its operational modes. 
SAVIOR-Cube functioned well throughout and after the TVAC test, proving it could 
survive extreme temperatures. Fortuitously, both the vibration and TVAC tests succeeded, 
and the payload design proved to be sound. SAVIOR-Cube was not only ready for a HAB 
flight, but it was vetted to survive the flight. 

F. SAVIOR-CUBE IS A GO FOR LAUNCH! 

With testing and design complete, flight operations were a go. To support a HAB 
flight, the SAVIOR-Cube payload was integrated into the 3U CubeSat HAB bus. The 
simple bus consisted of a bus computer and antenna, a global positioning system (GPS) 
tracker, a secondary GPS tracker called a SPOT Trace, and the electrical power system 
(EPS) consisting of both battery packs and two sets of solar panels (A and B), as the 
interface diagram in Figure 32 depicts. 
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Figure 32. Payload and Bus Interface 
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In terms of interfaces, the bus provided the payload with power via a custom power 
harness and supported communication between the two on-board computers. SAVIOR- 
Cube’s power harness simply connected to the EPS, receiving 5.00 V of power and up to 
1.50 A of current. For communication, a universal asynchronous receiver transmitter 
(UART) exchanged data between the two computers (payload and bus) and allowed for 
payload commanding from a mobile ground station during the flight. While Figure 32 
provides a schematic of the interfaces internal to the payload and from the payload to the 
bus. Appendix C depicts the formal interface schematic diagram. As a final pre-flight step, 
both the payload and bus were assembled in a 3D-printed 3U CubeSat structure seen in 
Figure 33—SAVIOR-Cube in its final pre-flight form. 
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Figure 33. SAVIOR-Cube Pre-Flight 


With SAVIOR-Cube assembled into the bus and ready for flight, a program called 
Habhub assisted in building a flight plan. Habhub is an open source website that calculates 
predicted flight paths, balloon burst altitude, and other important information for HAB 
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flights based upon local wind and weather predictions. With this information, a plan to fly 
SAVIOR-Cube 83 km east across California’s Central Valley provided a launch location, 
predicted landing location, and a flight time of approximately ninety minutes. At the launch 
location, a team of students and faculty attached the 3U CubeSat to a HAB filled with 
helium, as seen in Figure 34. 



Figure 34. Filling the High-Altitude Balloon 


Once the balloon was filled with helium, the team attached the CubeSat and 
powered the bus and payload on to ensure all systems were functioning. Multiple PRC152 
radios were assembled and tuned to communicate with SAVIOR-Cube, which had a final 
receive frequency of 145.25 MHz and a transmit frequency of 147.425 MHz. Using the 
PRC 152s, one final functional test of the payload proved it worked immediately prior to 
launch. With all systems a go, SAVIOR-Cube left the ground and began its journey into a 
near-space environment at approximately 1149 Pacific Standard Time (PST). Figure 35 is 
SAVIOR-Cube in-flight approximately five minutes after launch. 
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Figure 35. SAVIOR-Cube In-Flight 


For the first thirty minutes of the flight, the payload functioned admirably despite 
a few minor issues. It received transmissions from the PRCI52s, broadcasted the baseline 
transmission, and retransmitted recently recorded transmissions. Simply put, it successfully 
served as a VHF bent-pipe relay. The team began receiving and sending transmissions to 
SAVIOR-Cube approximately one minute prior to launch at 1148 PST. Approximately 
nine minutes after launch at 1158 PST, the payload malfunctioned and froze in a state of 
inoperability. It was manually rebooted via the mobile ground-station computer using a 
P 3 ^hon command (see Appendix B) and began working again at 1205 PST. After a 
successful reboot, the payload continued to function well, both sending and receiving 
transmissions. SAVIOR-Cube performed as expected for the first thirty minutes of the 
flight, receiving and sending a total of fourteen test transmissions. The flight was a success. 

However, a failure between the payload and bus occurred at approximately 1219 
PST, rendering the payload inoperable for the remainder of the flight. Based on the flight 
data, the power to the payload dropped below 4.00 V at 1219 PST, which is the absolute 
minimum amount of voltage the payload requires to function based upon the lab power 
tests. Figure 36 depicts payload voltage as a function of time, showing a voltage drop near 
1219. 
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Payload Voltage vs Time 
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Figure 36. Payload Voltage Versus Time 

Most likely, the low voltage caused critical failures within the payload, forcing a 
brownout. While it did reboot later in the flight, the team did not send or receive successful 
transmissions to SAVIOR-Cube for the remainder of the flight. The data recorded by the 
payload computer and bus computer, coupled with an analysis of the recorded audio 
transmissions and ground-based logs, indicate that the payload received its last successful 
transmission at that same approximate time—1219 PST. Correlating the last recorded 
latitude and longitude of the payload at 1218 PST (37.1283, -120.6146) with the latitude 
and longitude of the ground-based PRC152 radio at approximately 1219 PST (37.05676, - 
121.00082) gives a straight-line distance of 35.3 km between the two. Correlating this 
distance with the altitude of SAVIOR-Cube at that time of 9.67 km into account provides 
a slant range between the payload and radio of 36.6 km. Thus, SAVIOR-Cube functioned 
in-flight for approximately thirty minutes at a maximum distance of over 36 km, which 
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Figure 37 depicts. With this data, the initial proof of concept for an SDR VHF CubeSat 
relay succeeded. 


SAVIOR-Cube 



Figure 37. SAVIOR-Cube In-flight Slant Range 


Unfortunately, the CubeSat structure did not survive the landing. Winds at altitude 
caused a parachute malfunction, forcing one of the parachutes to deploy early and 
significantly increasing the distance and time of the flight, reaching a maximum altitude of 
approximately 21 km. As a result, SAVIOR-Cube eventually landed 120 km to the west of 
the launch site. Figure 38 compares the predicted and actual flight paths. 
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Figure 38. SAVIOR-Cube Flight Path 


Due the winds at altitude and the premature parachute deployment, the antennas 
also became entangled in the parachute cord and only one of the parachutes opened as a 
result. This caused a rough landing that shattered the 3U CubeSat structure. However, the 
3D-printed CubeSat structure and payload chassis were designed precisely for the purpose 
of absorbing the impact in the event of a rough landing to protect the bus and payload 
components. Figure 39 depicts SAVIOR-Cube as it was discovered post-flight. 



Figure 39. SAVIOR-Cube Post-Flight 
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Despite the rough landing, a post-flight functional test conducted in the lab was 
successful. After an initial reboot, it performed as designed, sending and receiving 
transmissions in the lab. SAVIOR-Cube survived the HAB test and flight, which validated 
the structural design. Despite the temperature fluctuation during the flight, power outages, 
and a very rough landing, SAVIOR-Cube still endured. Not only did the HAB flight prove 
the viability of the concept, but it also validated the payload design. 

G. CHAPTER CONCLUSION 

To ensure the concept of a VHP nanosatellite relay was realistic, SAVIOR-Cube 
required thorough testing. First, extensive bench testing in the laboratory and iterative 
operational and functional testing identified flaws in the payload design and solidified the 
SAVIOR-Cube hardware and software designs. Robust environmental testing ensured the 
payload would survive the stresses of a HAB flight. Most importantly, the success of the 
HAB flight demonstrates that the payload is designed to support the intended purpose of 
SAVIOR-Cube. This testing proves that an SDR-based VHF relay flown in a nanosatellite 
is a realistic and feasible concept. It could provide resiliency and redundancy to the U.S. 
SATCOM infrastructure and support SOF across the globe. While this chapter focuses on 
the extent of the testing SAVIOR-Cube endured, the next chapter concludes this study and 
provides recommendations for future research. 
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V. SUMMARY AND CONCLUSION 


As the body of this thesis demonstrates, the U.S. military is highly reliant upon 
space-based technology and special operations forces in particular (SOF) are nearly 
addicted to this advanced technology, conducting decentralized operations across the 
globe. Satellites support precision guided munitions, provide unparalleled overhead 
imagery, and enable global satellite communication (SATCOM). SATCOM especially 
supports U.S. SOF as they wage a far-reaching and decentralized conflict. However, as 
Chapter I explains, a high reliance upon the same technology that provides an edge to U.S. 
forces on the battlefield could also be a vulnerability. U.S. competitors undoubtedly 
possess the ability to disable U.S. satellites via kinetic or cyber means. Furthermore, the 
space domain is becoming ever more contested, and space-based technological resources 
are not infinite. While it would be unwise for the U.S. military and SOF in particular to 
divest from advanced technology due to the many advantages it provides, space-based 
resiliency and redundancy are required to help insulate against potential vulnerabilities. 

Fortunately, emerging technology in nanosatellites provides potential methods for 
building required protections. Nanosatellites offer low-cost and expedient solutions that 
support innovation and experimentation across space-based technologies. Their small- 
price tag makes them ideal for developing custom payloads and testing new ideas. 
Furthermore, their small form factor leads to low satellite mass and supports large 
constellation size, potentially allowing operationally responsive launch and orbit 
customization. In other words, nanosatellites and Cube Satellites (CubeSats) allow for 
cheap innovation to augment the U.S. space infrastructure with custom solutions. With this 
idea in mind specifically for SATCOM and U.S. SOF, enormous potential exists for 
developing nanosatellite payloads that build resiliency and redundancy into traditional 
SATCOM architecture. Traditional SATCOM utilizes ultra high frequency (UHF) bands 
and most line of sight (LOS) communication relies upon very high frequencies (VHF), 
creating a potential for innovation between VHF and SATCOM. Specifically, as this thesis 
demonstrates, a nanosatellite that offers VHF communication from low Earth orbit (LEO) 
merits exploration. Hence, the impetus for the Software Assisted VHE Information 

81 



Overhead Relay-CubeSat (SAVIOR-Cube). SAVIOR-Cube utilizes existing software- 
defined radio (SDR) technology augmented to provide VHP communication via a 
nanosatellite relay—a nanosatellite alternative to traditional SATCOM. 

The research, experimentation, and test results derived from this thesis illustrate 
that SAVIOR-Cube is a viable innovation. Chapter II demonstrates that SAVIOR-Cube is 
applicable to U.S. SOP today, feasible in terms of orbital mechanics, and realistic for 
implementation. More specifically, it shows how SOP across the globe today would benefit 
from a CubeSat that serves as a VHP relay overhead. Purthermore, example constellations 
demonstrate its feasibility, and a detailed communication budget from LEO validates that 
SAVIOR-Cube is realistic. In other words, a constellation of CubeSats programmed as a 
VHP relay will provide a redundant form of SATCOM to U.S. forces that could 
immediately support a myriad of operations from evasion plans to unconventional warfare 
campaigns. To further build upon this idea, a comprehensive trade space analysis in 
Chapter III results in the most favorable design for an initial engineering design unit (EDU) 
for a payload. The results of which were an EDU for SAVIOR-Cube that consists of a 
B205-Mini SDR, a Raspberry Pi 3 payload computer, a low noise amplifier for received 
signals, a wideband amplifier for transmitted signals, and two separate receive and transmit 
dipole antennas. This configuration, augmented by custom software programming via 
GNU Radio, allows SAVIOR-Cube to receive a VHE transmission, modulate the signal 
appropriately, amplify the signal, and retransmit it on a separate VHE frequency—a VHE 
bent-pipe relay. 

While Chapter I and II articulate the depth of the problem and a potential solution, 
and Chapter III further designs the concept via a trade space analysis, if SAVIOR-Cube is 
intended to fly in orbit one day, it requires in-depth testing. Thus, the payload hardware 
and software were iteratively tested on the laboratory bench, via functional and operational 
tests, through environmentally testing, and finally onboard a high-altitude balloon (HAB). 
The operational testing in the lab and functional testing outside the lab assisted in software 
and hardware refinement, leading to the most optimal design. Environmental testing 
ensured the SAVIOR-Cube was properly designed and would survive the rigors of a near- 
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space flight in a HAB. Finally, the HAB flight proved the viability of the payload and 
completed the regimen of iterative tests for SAVIOR-Cube. 

From the results of these tests, SAVIOR-Cube demonstrated that it would function 
as designed. Functional testing validated its ability to retransmit signals over a simulated 
distance of over 100 km. Onboard a HAB, it reached an altitude of close to 21 km, 
transmitted over a distance of 36 km, and functioned for approximately 30 minutes inflight. 
Initial SAVIOR-Cube testing and experimentation was a success, which is key for proving 
the viability of this payload and its potential applications. This regime of iterative tests not 
only led to the best design for the SAVIOR-Cube payload, but it also validated the 
hypothesis of this thesis by demonstrating that nanosatellites are a viable alternative to 
augment existing space-based architectures. 

A. POTENTIAL SAVIOR-CUBE APPLICATIONS 

Though SAVIOR-Cube has clear applications for U.S. SOF, its applicability goes 
beyond special operations. Within the military, conventional U.S. and allied forces could 
also benefit from a VHF relay as an alternative form of SATCOM. Additionally, such a 
payload could assist in military search and rescue operations, providing a redundant form 
of VHF communications. In terms of employment, CubeSats and nanosatellites are only 
one mode of transportation for SAVIOR-Cube. Both manned and unmanned aerial 
platforms could fly simple payloads such as SAVIOR-Cube to support short-duration 
missions. Tethered dirigibles could support a VHF relay as well, flying high-above large 
bases to expand local VHF capabilities. Alternatively, versions of SAVIOR-Cube spread 
around a metropolitan area could provide a mesh network of military VHF communication 
across a city or specific area target. For the U.S. military and its allies, the applications for 
a VHF relay are numerous. 

Beyond military applications, SAVIOR-Cube can support a number of civilian 
applications as well. First, it could serve as an emergency beacon during disaster and 
emergency events, broadcasting pre-recorded messages and instructions across a range of 
VHF frequencies. Next, the payload could also assist with civilian search and rescue 
operations, tying into maritime or emergency VHF frequencies and serving as a redundant 
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form of communication for those in need of rescue, from stranded climbers to wayward 
vessels in the ocean. Finally, SAVIOR-Cube could serve as a messaging service to remote 
areas with little communication infrastructure. A one-way radio service of sorts, sending 
VHF transmissions that could communicate with existing FM radios and provide weather 
updates, news, and much needed information to those lacking connectivity to the modem 
world. With the ease of programming SDRs and building nanosatellites, numerous options 
for SAVIOR-Cube applications and methods of employment exist beyond those discussed 
in this thesis. 

B. RECOMMENDATION FOR FUTURE WORK 

From the success of the SAVIOR-Cube EDU and testing, the potential for future 
design changes and additional experimentation exists. First in terms of the design, stronger 
amplifiers for both the received and transmitted signals would increase the distance across 
which the payload would function. Simply put, a more sensitive low noise amplifier would 
increase the margin for received signals, lowering the threshold for weakly received 
signals. A stronger transmit amplifier would increase the distance a transmitted signal 
could successfully travel and still reach its intended target. These changes would require 
more power, but a more robust satellite bus could support such a change. Furthermore, if 
intended to fly in orbit, stronger signals via more robust amplifiers and more power would 
be a requirement to ensure VHF signals successfully penetrate the Earth’s atmosphere. 
Additionally, a more capable SDR and payload computer would help fine-tune some of the 
issues caused by the limitations of the current design. Euture iterations of SAVIOR-Cube 
could include a custom SDR or computer, specifically designed with the payload’s purpose 
in mind. 

Akin to the hardware design, the software would also benefit from additional fine- 
tuning and experimentation. While the current software design for the payload functioned 
well, room for improvement always exists. Specifically, the software design and testing 
could be improved to support not just voice communication but also basic data 
transmissions. VHE is not ideal for data, but SAVIOR-Cube could support a simple data 
exchange if programmed appropriately. Similarly, the software could also be programmed 
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to support encrypted transmissions, shielding transmissions from intercept. It could also be 
designed to support multiple simultaneous transmissions, expanding the payload’s 
capabilities beyond its current limitations. Finally, the system could provide cross-linked 
communication within a constellation. It would expand beyond a bent-pipe relay to a truly 
global system. A future SAVIOR-Cube constellation could also tie into existing SATCOM 
systems such as the Mobile User Objective System (MUOS), moving beyond just this 
payload’s capabilities and tying into the U.S. SATCOM infrastructure writ large. These 
ideas are just a scratch on the surface of the numerous options for further SAVIOR-Cube 
development. Regardless, SAVIOR-Cube is a concept that merits further exploration and 
testing; it is a viable alternative to support U.S. military SATCOM needs. 

C. FINAL THOUGHTS 

As the research question of this study ponders, emerging technologies in 
nanosatellites are ripe for innovation aimed at protecting against space-based 
vulnerabilities. For example, a VHF relay flying overhead in orbit has numerous 
applications for U.S. SOF, the U.S. military and its allies, and even civilian populations. 
While the design, experimentation, and testing of SAVIOR-Cube support the utility of such 
a concept, the lessons of this thesis range beyond a simple SDR nanosatellite relay. With 
the potential vulnerabilities associated with the U.S. military’s dependence upon space- 
based resources such as SATCOM, SAVIOR-Cube simply provides an example solution 
to this otherwise exposed liability. More succinctly, it demonstrations that emerging 
technology in nanosatellites offer a testbed for innovation to build resiliency and 
redundancy into existing U.S. space-based infrastructure, thus validating the hypothesis of 
this thesis. The U.S. military must come to terms with its high reliance on advanced 
technology and build much needed protection into existing systems across all domains. 
Fortunately, nanosatellites provide a method for doing just that. Nanosatellites, however, 
are not just a viable alternative to traditional space-based architectures; they also provide 
an example for how to use emerging technology successfully, building redundancy and 
resiliency into legacy technological systems—a solution for a critical vulnerability. 
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APPENDIX A. GNU RADIO FLOW CHARTS 

A. RECEIVE FLOW CHARTS 
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Figure 40. Complete Receive Flow Graph 


Options 
ID: top.biock 

G enerate Optiorw: QT GUI 


;7ir 


OT GUI Rnone 


1 r 



QTGIlIRnoae I 1 OT Gill Rem 
«h rx.f _ □ X 

DefasJ 

General RF Options FE Conections Advanced Documentation 


OT GIM Range 
- □ X 

147M 


QT GUI Range 


UHD: USRP Source 
Device Address: sw 3120572 
Samp Rale |Sps)i SSk 
ChO: Cerder Req (Hr): 14«M 
ChO: Cain Value: -10 
ChO: Ardenr>a:RX2 
ChO: Bandwidth (Hr): 200k 


Wav Fite Source 
File: hstTra nsi i wmu i l nr 
Repeat: No 


Output type 
wire Format 
Stream args 
Stream channels 
Oevfce Address 
Device Arguments 
Sync 

Clock Rate (Ht) 
Num Mboards 
kR)0: Clock Source 
MbO: Time Source 
MbO: Subdev Spec 
Num Channels 
Samp Rate (Sps) 


uhd_usrp_source_0 
Complex float32 '' 
Automatic 


don't sync 

Default 

1 

Default 

Default 


General RF Options FE Corrections Advanced Co: lei iiatioo 



ChO: Center Freq (Hz) 

n(.freq 

ChO: Gam value 

miBin 

ChO: Gam lype 

Absolute (dB) '' 

ChO Antpnna 

RX2 

ChO; Bandwidth (Hz) 

200e3 





ChO: Cm Value: 80 
ChO: Ardenrra: TX/RX 
TSB tag narrw: 


Figure 41. USRP Source Blocks 
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Figure 42. Low Pass Filter, Power Squelch, and Automatic Gain Control Blocks 



Figure 43. File Sink Blocks 
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Figure 44. Wav File Souree, NBFM Transmit, and Rational Resampler Bloeks 
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Figure 45. USRP Sink Block 
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Figure 46. 
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Figure 47. File Source and USRP Sink Blocks 
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APPENDIX B. RAW PAYLOAD PYTHON SCRIPTS 


A. MASTER PYTHON SCRIPT (MASTER.PY)!''^ 

from_future_import print_function 

import os 
import shutil 
import socket 
import subprocess 
import sys 
#import cpu_temp 
import threading 
import time 
import log 
import serial 
import UART 

from store_and_forward import store_and_forward 
STATUSJNTERVAL = 20 

# C&DH serial connection variables 
CDH_address = 7dev/ttyAMA0" 

CDH_baud = 9600 

CDH = UART.UART(CDH_address, CDH_baud) 

STAT_STR = '20 {:>10d} {:>9d} {;>9d} {:>+3d} {:>2d} {;>+3d} {:>3d} {;>+5.1f} {;>6.1f}' 
ACK_STR = '21 {;>10d} {:>2d} {:>ld} {:>ld}' 

MSG_STR = '22 {:>100s}' 

LOGGER = log.LOGO 

# Payload variables 
VERSION = "0.1" 

def main(): 

# RX_freq, TX_freq, RX_gain, TX_gain, RX_thres, TX_delay 
params = [145525000, 147550000, -10, 80, -75, 60] 

msg = '\n\n-' 

LOGGER, log(msg) 

msg = '22 {;<100s}'.format('%d Payload Startup, version %s'%(time.time(), VERSION)) 
LOGGER, log(msg) 

CDH.write(msg, True) 

current_script = 'store_and_forward' 

error_msg = " 

try: 
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current_object = store_and_forward(params,CDH) 
current_obj ect.mnO 
except; 

error_msg = "ERROR; Radio connection failed." 
if error_msg; 

msg = error_msg 
else; 

msg = "SDR Ready to Receive" 
time.sleep(2) 
print(msg) 

LOGGER.log(msg) 

time2get_status = 0 
while True; 

now = time.timeO 

cmd = CDH.get_line() 
if cmd != None; 
cmd_id = None 
cmd_status = 0 
cmd = cmd.stripO 

msg = 'command <%s> received.'%cmd 

LOGGER.log(msg) 

print(msg) 

cmd_parts = cmd.split(" ") 
cmd = cmd_parts[0] 
if cmd == "pstat"; 
cmd_id = 20 
opt_id = 0 

status_str = update_status(params) 
time2get_status = time.time() + STATUSJNTERVAL 
if status_str is not None; 
cmd_status = 1 
print(status_str) 

CDH.write(status_str, True) 
elif cmd == "preboot"; 
cmd_id = 21 
opt_id = 0 

# REBOOT; Reboot the entire payload 

msg = MSG_STR.format('%d system reboot.'%now) 

print(msg) 

LOGGER.log(msg) 

msg = ACK_STR.format(int(now), cmd_id, opt_id, 1) 
print(msg) 

LOGGER.log(msg) 

CDH.write(msg, True) 

p = subprocess.Popen(['sync'], stdout=subprocess.PIPE, stderr=subprocess.PIPE) 

results, err = p.communicateQ 

p.waitO 

time.sleep(l) 

p = subprocess.Popen(['reboot'], stdout=subprocess.PIPE, stderr=subprocess.PIPE) 

results, err = p.communicate() 

p.waitO 
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while True: 
time.sleep(l) 
elif cmd == "preset": 
cmd_id = 22 
opt_id = 0 

# RESTART: Restart the current payload script 
if not current_script: 

print("no current script running") 
else: 

print("Attempt to restart script: " + current_script) 

failed = False 

try: 

current_object.stop() 

sleep(2) 

current_object = store_and_forward(params) 
current_object.run() 
except: 

failed = True 

msg = MSG_STR.format('Script failed to reset.') 
print(msg) 

LOGGER.log(msg) 

CDH.write(msg, True) 

if not failed: 

print("Restarted script <%s> successfully."%current_script) 
cmd_status = 1 
elif cmd == "padj": 
cmd_id = 23 
try: 

opt_id = int(cmd_parts[l]) 
adj_val = int(cmd_parts[2].rstrip('\0')) 

if len(cmd_parts) != 3 or opt_id < 1 or opt_id > 7: 

msg = MSG_STR.format('command <%s> is invalid.'%cmd) 
print(msg) 

LOGGER.log(msg) 

CDH.write(msg, True) 
continue 

if opt_id > 7: 

msg = 'command <%s> is invalid.'%cmd 
print(msg) 

LOGGER.log(msg) 
elif opt_id > 0 and opt_id < 7: 
opt_valid = False 

cmd_status = 1 # Assume successful now, unless exception 

params[opt_id-l] = adj_val #adjust to base zero 
if opt_id == 1: 

current_object.set_rx_freq(adj_val) 
elif opt_id == 2: 

current_object.set_tx_freq(adj_val) 
elif opt_id == 3: 

current_object.set_rx_gain(adj_val) 
elif opt_id == 4: 
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current_object.set_tx_gain(adj_val) 
elif opt_id == 5; 

current_object.set_rx_thres(adj_val) 
elif opt_id == 6; 

current_object.set_tx_delay(adj_val) 

except: 

msg = MSG_STR.format('command <%s> is invalid. Adjustment failed.'%cmd) 
print(msg) 

LOGGER.log(msg) 

CDH.write(msg, True) 
cmd_status = 0 

else: 

msg = MSG_STR.format('command <%s> is invalid. Unknown command type.'%cmd) 
print(msg) 

LOGGER.log(msg) 

CDH.write(msg, True) 

if cmd_id is not None: 

msg = ACK_STR.format(int(now), cmd_id, opt_id, cmd_status) 
print(msg) 

LOGGER.log(msg) 

CDH.write(msg, True) 

if now > time2get_status: 

status_str = update_status(params) 
time2get_status = time.time() + STATUS JNTERVAL 
if status_str is not None: 
print(status_str) 

CDH.write(status_str, True) 

def update_status(params): 

#temps = cpu_temp.get_temps() 

#if temps != None: 

# LOGGER.log(temps) 

p = os.popen('vcgencmd measure_temp').readline() # temperature values are stored inside of this file 
values = [float(p.replace("temp=",'"').replace("'C\n",""))] # remove 'C' => float 
cpu_temp = values [0] 

data = get_SD_capacity() 
now = time.timeO 
if data != None: 

(fs, size, used, avail, cap, mount) = data 
data_avail = float(avail)/(1024) 

msg = '22 {:<100s}'.format('%d SD available %s Mbytes'%(now, avail)) 

LOGGER.log(msg) 

# Return status string 

return STAT_STR.format(int(now), params[0], params[l], params[2], params[3], params[4], 
params[5], cpu_temp, data_avail) 

def get_SD_capacity(): 

p = subprocess.Popen(['df], stdout=subprocess.PIPE, stderr=subprocess.PIPE) 

results, err = p.communicate() 

p.waitO 
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cap = None 

for line in results.split("\n"): 
if line.find(7dev/root') >= 0; 
try: 

(fs, size, used, avail, cap, mount) = line.split() 
return (fs, size, used, avail, cap, mount) 
except: 

return None 
return None 

if_name_== "_main_": 

os.nice(-19) 

main() 

B. STORE FORWARD PYTHON SCRIPT (STORE.AND.FORWARD.PY)!"® 

from_future_import print_function 

import log 

import time 

import threading 

import subprocess 

import UART 

from saf_rx import saf_rx 

from saf_tx import saf_tx 

RX_STR = "RX Started. RX_Freq: {:>9d}. RX_Gain: {:>+3d}. RX_Thres: {:>+3d}. TX_Freq: {:>9d}. 
TX_Gain: {:>2d}." 

MSG_STR = '22 {:>100s}' 

LOGGER = log.LOGO 

class store_and_forward(object): 

def_init_(self,params,CDH): 

self.rx_freq = params[0] 
self.tx_freq = params[l] 
self.rx_gain = params[2] 
self.tx_gain = params[3] 
self.rx_thres = params[4] 
self.tx_delay = params[5] 
self.CDH = CDH 

self.rx_obj = None 
self.tx_obj = None 

self.thread = threading.Thread(target=self.run_thread, args=(self.rx_obj,self.tx_obj)) 
self.thread.daemon = True 

def get_params(self): 

return [self.rx_freq, self.tx_freq, self.rx_gain, self.tx_gain, self.rx_thres, self.tx_delay] 

def get_rx_freq(self): 
return self.rx_freq 
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def set_rx_freq(self, rx_freq): 
self.rx_freq = rx_freq 
if self.rx_obj is not None: 

self.rx_obj .set_rx_freq(rx_freq) 

def get_tx_freq(self): 
return self.tx_freq 

def set_tx_freq(self, tx_freq): 
self.tx_freq = tx_freq 
if self.rx_obj is not None: 

self.rx_obj .set_tx_freq(tx_freq) 
if self.tx_obj is not None: 

self.tx_obj .set_tx_freq(tx_freq) 

def get_rx_gain(self): 
return self.rx_gain 

def set_rx_gain(self, rx_gain): 
self.rx_gain = rx_gain 
if self.rx_obj is not None: 

self.rx_obj .set_rx_gain(rx_gain) 

def get_tx_gain(self): 
return self.tx_gain 

def set_tx_gain(self, tx_gain): 
self.tx_gain = tx_gain 
if self.rx_obj is not None: 

self.rx_obj .set_tx_gain(tx_gain) 
if self.tx_obj is not None: 

self.tx_obj.set_tx_gain(tx_gain) 

def get_rx_thres(self): 
return self.rx_thres 

def set_rx_thres(self, rx_thres): 
self.rx_thres = rx_thres 
if self.rx_obj is not None: 

self.rx_obj.set_rx_thres(rx_thres) 

def run(self): 

self.thread.startO 

def stop(self): 

self.thread.terminateO 
if self.rx_obj is not None: 
self.rx_obj .stop() 

def run_thread(self, rx_obj, tx_obj): 
cycles = 0 
while cycles <10: 
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cycles = cycles + 1 

# Wait to transmit until after tx_delay 
self.rx_obj = rx_obj = saf_rx(self.get_params()) 
rx_obj.start() 

time.sleep(3) # 3 seconds to initialize 

msg = RX_STR.format(self.rx_freq,self.rx_gain,self.rx_thres,self.tx_freq,self.tx_gain) 
print(msg) 

LOGGER.log(msg) 

time2tx = time.time() + self.tx_delay 

while time.timeO < time2tx: 

# Send preface message and RX (STORE) 
time.sleep(l) 
printC'RXing") 
rx_obj.stop() 
rx_obj. wait() 
msg = "RX Stopped" 
print(msg) 

LOGGER.log(msg) 

time.sleep(2) # 2 seconds to cleanup 

# Start sending stored message (EORWARD) 
self.tx_obj = tx_obj = saf_tx(self.get_params()) 
tx_obj .start() 

msg = "TX Started. Ereq: %d. Gain: %d"%(tx_obj.tx_freq,tx_obj.tx_gain) 

tx_obj .wait() 

print(msg) 

LOGGER.log(msg) 

printC'TX Stopped") 

time.sleep(2) # 2 seconds to cleanup 

msg = MSG_STR.format('Automatic reboot started.') 
print(msg) 

LOGGER.log(msg) 
self.CDH.write(msg, True) 

p = subprocess.Popen(['sync'], stdout=subprocess.PIPE, stderr=subprocess.PIPE) 

results, err = p.communicate() 

p.waitO 

time.sleep(l) 

p = subprocess.Popen(['reboot'], stdout=subprocess.PIPE, stderr=subprocess.PIPE) 
results, err = p.communicate() 
p.waitO 
while True: 
time, sleep) 1) 

C. RECEIVE PYTHON SCRIPT (SAF_RX.PY)i«^ 

#!/usr/bin/env python2 
# coding: utf-8 


Koeppen. 


99 



# GNU Radio Python Flow Graph 

# Title: SafRx 

# Generated: Wed Feb 28 14:10:36 2018 


from gnuradio import analog 

from gnuradio import blocks 

from gnuradio import eng_notation 

from gnuradio import filter 

from gnuradio import gr 

from gnuradio import uhd 

from gnuradio.eng_option import eng_option 

from gnuradio.filter import firdes 

from optparse import OptionParser 

import time 

DEFAULT_PARAMS = [145525000, 147550000, -10, 80, -75] 
class saf_rx(gr.top_block): 

def _init_(self, params=DEFAULT_PARAMS): 
gr.top_block._init_(self, "Store and Eorward RX") 



self.rx_freq = rx_freq = params[0] 
self.tx_freq = tx_freq = params[l] 
self.rx_gain = rx_gain = params[2] 
self.tx_gain = tx_gain = params[3] 
self.rx_thres = rx_thres = params[4] 

self.samp_rate = samp_rate = 88000 
self.audio_rate = audio_rate = 44000 



self.uhd_usrp_source_0 = uhd.usrp_source( 
",".join(('serial=312D572',"")), 
uhd.stream_args( 

cpu_format="fc32", 
channels=range( 1), 

), 

) 

self.uhd_usrp_source_0.set_samp_rate(samp_rate) 
self.uhd_usrp_source_0.set_center_freq(rx_freq, 0) 
self.uhd_usrp_source_0.set_gain(rx_gain, 0) 
self.uhd_usrp_source_0.set_antenna('RX2', 0) 
self.uhd_usrp_source_0.set_bandwidth(200e3, 0) 
self.uhd_usrp_sink_0_0 = uhd.usrp_sink( 
",".join(('serial=312D572',"")), 
uhd.stream_args( 
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cpu_format="fc32", 

channels=range(l), 

), 

) 

self.uhd_usrp_sink_0_0.set_samp_rate(samp_rate) 
self.uhd_usrp_sink_0_0.set_center_freq(tx_freq, 0) 
self.uhd_usrp_sink_0_0.set_gain(tx_gain, 0) 
self.uhd_usrp_sink_0_0.set_antenna('TX/RX', 0) 
self.rational_resampler_xxx_0_0 = filter.rational_resampler_ccc( 
interpolation=l, 
decimation= 1, 
taps=None, 
fractional_bw=None, 

) 

self.low_pass_fdter_0 = filter.fir_filter_ccf( 1, firdes.low_pass( 

1, samp_rate, 5e3, 500, firdes.WIN_HAMMING, 6.76)) 
self.blocks_wavfile_source_0 = blocks. wavfde_source(yhome/pi/SDRcontrol/Files/S AVIOR- 
Cube.wav', False) 

self.blocks_file_sink_0_0 = blocks.fde_sink(gr.sizeof_gr_complex*l, yhome/pi/SDRcontrol/Files/ 
StoreForward_SaveFile', True) 

self.blocks_file_sink_0_0.set_unbuffered(False) 

self.blocks_file_sink_0 = blocks.file_sink(gr.sizeof_gr_complex*l, '/home/pi/SDRcontrol/Files/ 
StoreForward_file', False) 

self.blocks_file_sink_0.set_unbuffered(False) 

self.analog_pwr_squelch_xx_0 = analog.pwr_squelch_cc(rx_thres, le-4, 0, True) 
self.analog_nbfm_tx_0 = analog.nbfm_tx( 
audio_rate=audio_rate, 
quad_rate=audio_rate * 2, 
tau=75e-6, 
max_dev=5e3, 
fh=-1.0, 

) 

self.analog_agc_xx_0 = analog.agc_cc(le-4, 1, 1.0) 
self.analog_agc_xx_0.set_max_gain( 100000) 



self.connect((self.analog_agc_xx_0, 0), (self.blocks_file_sink_0, 0)) 
self.connect((self.analog_agc_xx_0, 0), (self.blocks_file_sink_0_0, 0)) 
self.connect((self.analog_nbfm_tx_0, 0), (self.rational_resampler_xxx_0_0, 0)) 
self.connect((self.analog_pwr_squelch_xx_0, 0), (self.analog_agc_xx_0, 0)) 
self.connect((self.blocks_wavfile_source_0, 0), (self.analog_nbfm_tx_0, 0)) 
self.connect((self.low_pass_filter_0, 0), (self.analog_pwr_squelch_xx_0, 0)) 
self.connect((self.rational_resampler_xxx_0_0, 0), (self.uhd_usrp_sink_0_0, 0)) 
self.connect((self.uhd_usrp_source_0, 0), (self.low_pass_filter_0, 0)) 

def get_tx_gain(self): 
return self.tx_gain 

def set_tx_gain(self, tx_gain): 
self.tx_gain = tx_gain 

self.uhd_usrp_sink_0_0.set_gain(self.tx_gain, 0) 
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def get_tx_freq(self): 
return self.tx_freq 

def set_tx_freq(self, tx_freq): 
self.tx_freq = tx_freq 

self.uhd_usrp_sink_0_0.set_center_freq(self.tx_freq, 0) 

def get_samp_rate(self): 
return self.samp_rate 

def set_samp_rate(self, samp_rate): 
self.samp_rate = samp_rate 

self.uhd_usrp_source_0.set_samp_rate(self.samp_rate) 

self.uhd_usrp_sink_0_0.set_samp_rate(self.samp_rate) 

self.low_pass_filter_0.set_taps(firdes.low_pass(l, self.samp_rate, 5e3, 500, firdes.WIN_HAMMING, 
6.76)) 

def get_rx_thres(self): 
return self.rx_thres 

def set_rx_thres(self, rx_thres): 
self.rx_thres = rx_thres 

self.analog_pwr_squelch_xx_0.set_threshold(self.rx_thres) 

def get_rx_gain(self): 
return self.rx_gain 

def set_rx_gain(self, rx_gain): 
self.rx_gain = rx_gain 

self.uhd_usrp_source_0.set_gain(self.rx_gain, 0) 


def get_rx_freq(self): 
return self.rx_freq 

def set_rx_freq(self, rx_freq): 
self.rx_freq = rx_freq 

self.uhd_usrp_source_0.set_center_freq(self.rx_freq, 0) 

def get_audio_rate(self): 
return self.audio_rate 

def set_audio_rate(self, audio_rate): 
self.audio_rate = audio_rate 


def main(top_block_cls=saf_rx, options=None): 


tb = top_block_cls() 

tb.startO 

tb.waitO 
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if_name_== '_main_ 

main() 

D. TRANSMIT PYTHON SCRIPT (SAF.TX.PY)!"’ 


#!/usr/bin/env python2 
# coding: utf-8 


# GNU Radio Python Flow Graph 

# Title: SafTx 

# Generated: Wed Feb 28 14:10:41 2018 


from gnuradio import blocks 

from gnuradio import eng_notation 

from gnuradio import gr 

from gnuradio import uhd 

from gnuradio.eng_option import eng_option 

from gnuradio.filter import firdes 

from optparse import OptionParser 

import time 

DEFAULT_PARAMS = [145525000, 147550000, -10, 80, -75] 
class saf_tx(gr.top_block): 

def _init_(self, params=DEFAULT_PARAMS): 
gr.top_block._init_(self, "Store and Eorward TX") 



self.tx_freq = tx_freq = params[l] 
self.tx_gain = tx_gain = params[3] 

self.samp_rate = samp_rate = 88000 



self.uhd_usrp_sink_0 = uhd.usrp_sink( 
",".join(('serial=312D572',"")), 
uhd.stream_args( 

cpu_format="fc32", 
channels=range( 1), 

), 

) 

self.uhd_usrp_sink_0.set_samp_rate(samp_rate) 
self.uhd_usrp_sink_0.set_center_freq(tx_freq, 0) 
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self.uhd_usrp_sink_0.set_gain(tx_gain, 0) 
self.uhd_usrp_sink_0.set_antenna('TX/RX', 0) 
self.uhd_usrp_sink_0.set_bandwidth(10e3, 0) 

self.blocks_file_source_0 = blocks.file_source(gr.sizeof_gr_complex*l, 7home/pi/SDRcontrol/Files/ 
StoreForward_file', False) 



self.connect((self.blocks_file_source_0, 0), (self.uhd_usrp_sink_0, 0)) 

def get_tx_gain(self): 
return self.tx_gain 

def set_tx_gain(self, tx_gain): 
self.tx_gain = tx_gain 

self.uhd_usrp_sink_0.set_gain(self.tx_gain, 0) 
self.uhd_usrp_sink_0.set_gain(self.tx_gain, 1) 


def get_tx_freq(self): 
return self.tx_freq 

def set_tx_freq(self, tx_freq): 
self.tx_freq = tx_freq 

self.uhd_usrp_sink_0.set_center_freq(self.tx_freq, 0) 
self.uhd_usrp_sink_0.set_center_freq(self.tx_freq, 1) 

def get_samp_rate(self): 
return self.samp_rate 

def set_samp_rate(self, samp_rate): 
self.samp_rate = samp_rate 

self.uhd_usrp_sink_0.set_samp_rate(self.samp_rate) 


def main(top_block_cls=saf_tx, options=None): 

tb = top_block_cls() 

tb.startO 

tb.waitO 

if_name_== '_main_ 

main() 

E. UART PYTHON SCRIPT (UART.PY)!®* 

from_future_import print_function 
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import threading 
import time 
import Queue 
import serial 
import sys 
import time 

class UART(object): 

def_init_(self, port, baudrate, eol='\xOA'): 

self.eol = eol 
self.buff = "" 

self.ser = serial.Serial(port=port, baudrate=baudrate, bytesize=8, parity='N', stopbits=l, 
timeout=0, xonxoff=0, rtscts=0) 

self.ser.flushlnputO 
self.ser.flushOutputO 
self.queue = Queue.QueueQ 

self.thread = threading.Thread(target=self.enqueue_output, args=(self.queue,)) 
self.thread.daemon = True 
self.thread.startO 


def enqueue_output(self, queue): 

# run forever, looking for a line and putting it in the queue 
while True: 

queue.put(self.build_line()) # this blocks! 


def build_line(self): 

while True: 

n = self.ser.inWaitingO 
if n == 0: 

time.sleep(0.05) 

continue 

data = self.ser.read(n) 
self.buff = self.buff + data 
i = self.buff.find(self.eol) 
ifi>= 0: 

s = self.buff[:i] 

self.buff = self.buff[i+len(self.eol):] 
return s 


def get_line(self, timeout=0.01): 
try: 

line = self.queue.get(timeout=timeout) 
except Queue .Empty: 
return None 

else: 

return line 


def write(self, data, send_eol=False): 
if send_eol: 
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self.ser.write(data+self.eol) 

else: 

self.ser.write(data) 


def write_print(self, data, send_eol=False): 
print(data) 

self.write(data+'\r\n', send_eol) 


if_name_== "_main_": 

# this only happens when this module is NOT imported, but is run as 'sudo python radio.py' 
link = UART(7dev/ttyAMA0", 9600) #changed from tty## to ttyAMAO 
# radio = RADIO("COM6", 9600, eol='@ @ @') 

count = 0 
while True: 

no_msg = True 

msg = link.get_line() # this is NOT blocking! 

if msg != None: 

no_msg = False 

tstr = time.strftime('%Y-%m-%d %H:%M:%S') 
t = time.timeO 

print("%1.3f: %s" %(t, msg)) 
link.write('%d'%count) 
count += 1 

if no_msg: 


106 



APPENDIX C. PAYLOAD AND BUS SCHEMATICS 



Figure 48. Payload and Bus Schematic Page 


Source: Ronald Phelps, email message to author, February 21, 2018. 
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Figure 49. Payload and Bus Schematic Page 


Source: Phelps. 
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Figure 50. Bus Electrical Power System Schematic'^' 


^ 1 ^ Source: Phelps. 
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APPENDIX D. THESIS POSTER 


Critical Vulnerabilities in the Space Domain: 
Nanosatellites as an Alternative to 
Traditional Satellite Architectures 


Today, the U.S. military relies upon space-based technology for a myriad of functions from precision navigation to 
satellite communication. However, the United States is highly reliant upon this technology and thus increasingly 
vulnerable with potential adversaries cultivating the ability to attack America's space-based infrastructure. As a 
safeguard against such vulnerabilities, nanosatellites, cube satellites (CubeSats), and other small satellites are a low- 
cost and expedient solution to build redundancy and resiliency, offering unique options as an alternative to 
traditional satellite systems. To support this hypothesis, this thesis provides such an alternative: A Software Assisted 
VHP Information Overhead Relay-CubeSat (SAVIOR-Cube). SAVIOR-Cube is a softwai’e-defined radio (SDR) 
payload operating as a very high frequency (VHP) relay via a nanosatellite in low Earth orbit. This thesis 
demonstrates the depth of the problem a payload such as SAVIOR-Cube could solve, the applicability of 
nanosatellite solutions to U.S. forces today, and the results of extensive testing, culminating with a proof of concept 
high-altitude balloon (HAB) flight. 



Postgraduate 


The Software-Assisted VHP Information Overhead Relay-CnbeSat (SAVIOR-Cnhe) 



SAVIOR-Cube Concept of Operations 


Method and Approach 

• Illuminate the depth of the U.S. military’s reliance 
on space-based technology. 

• Understand the critical vulnerabilities this 
dependence creates. 

• Research potential nanosatellite solutions. 

• Build a model constellation and concept of 
operations for a VHP nanosatellite relay. 

• Using Ettus Corporation’s B205-Mini SDR, 
develop a prototype payload. 

• Iteratively test the payload in and out of the 
laboratory environment. 

• Integrate the payload into a CubeSat and launch it 
via a HAB to replicate a near-space environment. 


Testing and Results 

• Survived temperatures ranging from 70°C to -45°C 
during thermal-vacuum chamber testing. 

• Endured vibration testing across all three axes via 
extensive vibration-table testing. 

• Successfully communicated across a simulated distance 
of 100 km during line of sight field tests. 

• Punctioned for 30 minutes at altitude during HAB 
flight, sending and receiving 14 separate transmissions. 

• Reached a maximum altitude of 21 km (70,000 ft). 

• Communicated over a maximum slant-range of 36 km. 

• A successful proof of concept test and design for a 
VHP nanosatellite relay. 



SAVIOR-Cube 


SAVIOR-Cube enables non-SATCOM capable VHP radios in a degraded space 
environment—a solution to a critical vulnerability 



Thesis Author: Major Philip Swintek, Student, Defense Analysis / Space Systems Operations 
Thesis Advisors: Dr. Leo Blanken, Associate Professor, Department of Defense Analysis; 

Dr. Wenschel Lan, Senior Lecturer, Space Systems Academic Group 

Lieutenant Colonel Scott Moore, Military Assistant Professor, Space Systems Academic Group 
Thesis Sponsor: Space and Naval Warfare Systems Center-Pacific 


Figure 51. Thesis Poster 
111 















THIS PAGE INTENTIONALLY LEET BLANK 


112 



LIST OF REFERENCES 


Alberts, David S., John J. Garstka, Richard E. Hayes, and David A. Signori. 

“Understanding Information Age Warfare.” Command and Control Research 
Portal Publication Series (August 2001). 

Amateur Radio on the International Space Station. “Contact the ISS.” Accessed 
November 3, 2017. http://www.ariss.org/contact-the-iss.htnil. 

Blanken, Leo J., and Jason J. Lepore. “Unpacking the Various Meanings of Redundancy: 
from Refining the Concept to Military Planning.” Defense & Security Analysis, 
28:4 (November 2012): 326-342. 

Bousquet, Antoine J. The Scientific Way of Warfare: Order and Chaos on the Battlefields 
of Modernity. New York: Columbia University Press, 2009. 

Bryant, Steven L. “The Dangers of an Overreliance on Advanced Technology.” Master’s 
thesis. National Defense University, 2011. 

Byonics EEC. “MicroTrak VHE Antennas.” Accessed 04 Eebruary 2018. 
http ://w w w .byonic s. com/antennas. 

Cynamon, Chuck. “Military Satellite Communications.” Air Eorce Space Command. 
Eebruary 2010. Accessed April 14, 2017. https://afcea-la.org/sites/afcea-la.org/ 
files/AECEA%20Brief%20Eeb2010.pdf. 

David, Leonard. “China, Russia Advancing Anti-Satellite Technology, U.S. Intelligence 
Chief Says.” Space.com, May 18, 2017. https://www.space.com/36891-space- 
war-anti-satellite-weapon-development.html. 

De Week, Olivier L., Uriel Scialom, and Afreen Siddiqi. “Optimal Reconfiguration of 
Satellite Constellations with the Auction Algorith."' Acta Astronautica 62, 
(Eebruary 2008): 112-130. 

eoPortal Directory. “Iridium Next.” Accessed 03 December 2017. 

https://direct 0 ry.e 0 p 0 rtal. 0 rg/web/e 0 p 0 rtal/satellite-missi 0 ns/i/iridium-next. 

eoPortal Directory. “SkySat Constellation of Terra Bella - Eormerly SkySat Imaging 
Program of Skybox Imaging.” Accessed Eebruary 28, 2018. 
https://direct 0 ry.e 0 p 0 rtal. 0 rg/web/e 0 p 0 rtal/satellite-missi 0 ns/s/skysat. 

Ettus Research. “USRP B200mini Series.” 2017. https://www.ettus.com/content/files/ 
USRP_B200mini_Data_Sheet.pdf. 

Ettus Research. “USRP E310.” 2017. https://www.ettus.com/content/files/ 

USRP_E310_Datasheet.pdf. 


113 



Gordon, Gary D. and Walter L. Morgan. Principles of Satellite Communications. New 
York: John Wiley and Sons, Inc., 1993. 

Grauer, Ryan. Commanding Military Power: Organizing for Victory and Defeat on the 
Battlefield. Cambridge: Cambridge University Press, 2016. 

Harris Corporation. “Harris III AN/PRC-117G(V) 1(C),” 2017. https://www.harris.com/ 
sites/default/files/downloads/solutions/an-prc-117g-multiband-networking- 
manpack-radio-datasheet.pdf. 

Harris Corporation. “Harris Falcon III AN/PRC-I52A,”20I7. https://www.harris.com/ 
sites/default/files/downloads/solutions/harris-falcon-iii-an-prc-I52a-wideband- 
networking-handheld-radio.pdf 

Holmes, Mark. “LEO: Two Generations Share Their Outlooks.” Via Satellite, February 
2017. http://interactive.satellitetoday.com/via/february-2017/low-earth-orbit-two- 
generations-share-their-outlooks/. 

Innovative Solutions in Space. “CubeSats in Brief.” Accessed December 25, 2017. 
https://www.isispace.nl/cubesats/. https://www.isispace.nl/cubesats/. 

Koebler, Jason. “Solar-Powered Blimps Are the New Satellites.” Motherboard, March 6, 
2014. https://motherboard.vice.com/en_us/article/solar-powered-blimps-are-the- 
new-satellites. 

Lindon, Darin. “Assured Communications: Global Coverage, Communications 

Overmatch, Enhance Expeditionary Mission Command, Protect the Network.” 
U.S. Army Space and Missile Defense Command / Army Forces Strategic 
Command. 

Eockheed Martin. “Mobile User Objective System: Revolutionizing Secure 
Communications for Mobile Forces.” Accessed September 4, 2017. 
http://www.lockheedmartin.com/us/products/mobile-user-objective-system— 
muos-.html. 

Eoge, Ears. “Arctic Communications System Utilizing Satellites in Highly Elliptical 

Orbits.” Doctoral thesis, Norwegian University of Science and Technology, 2013. 

Marinan, Anne, and Kerri Cahoy. “From CubeSats to Constellations: Systems Design and 
Performance Analysis.” Master’s thesis, Massachusetts Institute of Technology, 
2013. 

Matassa, Chuck K. “.Comparing the Capabilities and Performance of the Ultra High 

Frequency Follow-On System with the Mobile User Objective System.” Master’s 
thesis. Naval Postgraduate School, 2011. 


114 



Meilinger, Phillip S. “American Military Culture and Strategy.” Joint Forces Quarterly, 
46, (October 2007): 80-86. 

Milne, J. Scott Jr. and Daniel S. Kaufman. “General Environmental Verification 

Specification.” Goddard Spaceflight Center. January 1, 2003. Accessed April 3, 
2018. https://ntrs.nasa.gOv/archive/nasa/casi.ntrs.nasa.gov/20030106019.pdf. 

Mini-Circuits. “ZX60-V63-I- Wideband Amplifier.” 2017. Accessed February 4, 2018. 
https://www.minicircuits.com/pdfs/ZX60-V63-i-.pdf. 

Mini-Circuits. “ZX60-V82-I- Wideband Amplifier.” 2017. Accessed February 4, 2018. 
https://www.minicircuits.com/pdfs/ZX60-V82-i-.pdf. 

The National Association for Amateur Radio. “US Amateur Radio Frequency 

Allocations.” Accessed 03 December 2017. http://www.arrl.org/frequency- 
allocations. 

National Instruments. “Software Defined Radio: Past, Present, and Future.” March 30, 
2017. Accessed December 2, 2017. http://www.ni.com/white-paper/53706/en/. 

Poole, Ian. “Radio Waves and the Ionosphere.” QST (November 1999). Accessed 

December 14, 2017. https://www.arrl.org/files/file/Technology/pdf/119962.pdf. 

Pulse Electronics. “Antenna Basic Concepts.” 2018. Accessed February 4, 2018.. 
https://www.pulseelectronics.com/antenna_basic_concepts/. 

Raspberry Pi Feaming Resources. “Raspberry Pi Hardware Guide.” Raspberry Pi 

Fearning Resources. Accessed January 8, 2018. https://www.raspberrypi.org/ 
learning/hardware-guide/. 

Science World Report. “US Must Deter Chinese Aggression In Space And Be Ready For 
War.” February 9, 2017. http://www.scienceworldreport.com/articles/56959/ 
20170209/deter-chinese-aggression-space-ready-war-general.htm. 

Sciutto, Jim. “US Military Readies for Next Frontier: Space War.” CNN, November 29, 
2016. http://www.cnn.eom/2016/ll/28/politics/space-war-us-military- 
preparations/index.html. 

Sellers, Jerry Jon, et al. Understanding Space: An Introduction to Astronautics. 3rd ed. 
New York: McGraw-Hill Companies, 2005. 

U.S. Air Force. “Wideband Global SATCOM Satellite.” 2015. http://www.af.mil/About- 
Us/Fact-Sheets/Display/Article/104512/wideband-global-satcom-satellite/. 

U.S. Army Signal Center of Excellence. “The Army Satellite Communications 
Architecture Book.” Fort Gordon, GA: 2013. 


115 



VanPutte, Michael A. Walking Wounded: Inside the U.S. Cyberwar Machine. 
CreateSpace Independent Publishing Platform, 2016. 

Williams, Andrew. “Raspberry Pi 3 vs Pi 2: What’s the Difference.” Trusted Reviews, 
February 29, 2016. Accessed January 8, 2018. http://www.trustedreviews.com/ 
opinion/raspberry-pi-3-vs-pi-2-2936374. 


116 



INITIAL DISTRIBUTION LIST 


1. Defense Technical Information Center 
Ft. Bel voir, Virginia 

2. Dudley Knox Library 
Naval Postgraduate School 
Monterey, California 


117 



